CognaLearn | Accessibility Statement

Web Content Accessibility Guidelines 2.1

Level A - Yes / No
Level AA - Yes / No
Level AAA - Yes / No

Revised Section 508 standards published January 18, 2017 and corrected January 22, 2018

EN 301 549 Accessibility requirements suitable for public procurement of ICT products and services in Europe, - V3.1.1 (2019-11)

1.1.1. Non-text Content (Level A)

Non-text Content
All non-text content that is presented to the user has a text alternative that serves the equivalent purpose, except for the situations listed below.

1. Controls, Input: If non-text content is a control or accepts user input, then it has a name that describes its purpose. (Refer to Success Criterion 4.1.2 for additional requirements for controls and content
   that accepts user input.)
   
2. Time-Based Media: If non-text content is time-based media, then text alternatives at least provide descriptive identification of the non-text content. (Refer to Guideline 1.2 for additional requirements for media.)
   
3. Test: If non-text content is a test or exercise that would be invalid if presented in text, then text alternatives at least provide descriptive identification of the non-text content.
   
4. Sensory: If non-text content is primarily intended to create a specific sensory experience, then text alternatives at least provide descriptive identification of the non-text content.
   
5. CAPTCHA: If the purpose of non-text content is to confirm that content is being accessed by a person rather than a computer, then text alternatives that identify and describe the purpose of the non- text content are provided, and alternative forms of CAPTCHA using output modes for different types of sensory perception are provided to accommodate different disabilities.
   
6. Decoration, Formatting, Invisible: If non-text content is pure decoration, is used only for visual formatting, or is not presented to users, then it is implemented in a way that it can be ignored by assistive technology.

https://www.w3.org/WAI/WCAG22/Understanding/non-text-content.html

Teacher App

Supports

Student App

Supports 

1. Images  and other visual sensory elements have alt text and these text alternatives are meaningful and relevant to the context of the page.
   
   
2. Decorative images have empty alt text and are excluded from assistive technology output.
   
   
3. Icons have aria- labels for screen readers.

Next review period: September 2025.

1.2.1. Audio-only and Video-only (Prerecorded) (Level A)

Audio-only and Video-only (Prerecorded)
For prerecorded audio-only and prerecorded video-only media, the following are true, except when the audio or video is a media alternative for text and is clearly labeled as such:

Prerecorded Audio-only: An alternative for time-based media is provided that presents equivalent information for prerecorded audio-only content.

Prerecorded Video-only: Either an alternative for time-based media or an audio track is provided that presents equivalent information for prerecorded video-only content.

https://www.w3.org/WAI/WCAG22/Understanding/audio-only-and-video-only-prerecorded.html

Teacher App

Not Applicable

Student App

Not Applicable

1. No Native Media:
   InteDashboard does not generate or include any audio-only or video-only media for both Instructor and Learner Apps. Therefore, no transcripts or text descriptions are required for app-provided content.
   
   
2. User-Uploaded Media:
   Instructors and staff user roles can upload media files (audio or video) as part of quiz content. While the app cannot enforce compliance directly, it provides tools and guidance to help users ensure accessibility.
   
   Example: When uploading media, the app prompts users to provide a corresponding text alternative (e.g., a transcript or description).
   
   
3. Support for Accessibility Features:
   InteDashboard supports the inclusion of alternative text fields and instructions for uploaded media to meet WCAG 1.2.1 requirements.
   
   Example: Users can enter or attach a transcript when uploading an audio file or provide a description for video-only media.
   
   
4. Responsibility of Content Creators:
   Compliance for user-uploaded media depends on the individual users who create and publish the activity content. InteDashboard facilitates accessibility but cannot guarantee adherence unless the users provide the necessary alternatives.

Next review period: September 2025.

1.2.2. Captions (Prerecorded) (Level A)

Captions (Prerecorded)
Captions are provided for all prerecorded audio content in synchronized media, except when the media is a media alternative for text and is clearly labeled as such.

https://www.w3.org/WAI/WCAG22/Understanding/captions-prerecorded.html

Teacher App

Not Applicable

Student App

Not Applicable

InteDashboard itself does not include any prerecorded videos with audio.

Since the app does not feature any prerecorded video content with audio, this criterion does not apply to app-generated media. However, the app supports user-uploaded videos and encourages content creators to include captions for accessibility.

Next review period: September 2025.

1.2.3. Audio Description or Media Alternative (Prerecorded) (Level A)

Audio Description or Media Alternative (Prerecorded)
Captions are provided for all live audio content in synchronized media.

https://www.w3.org/WAI/WCAG22/Understanding/audio-description-or-media-alternative-prerecorded.html

Teacher App

Not Applicable

Student App

Not Applicable

InteDashboard does not include prerecorded video content with visual elements that require audio descriptions.

As InteDashboard does not feature prerecorded videos with visual content (e.g., videos without narration), the requirements for audio descriptions or media alternatives do not apply. However, InteDashboard provides avenues for users to provide audio descriptions when they upload videos with important visual elements for the consumption of their learners, students and audience.

Next review period: September 2025.

1.3.1. Info and Relationships (Level A)

Info and Relationships
Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.

https://www.w3.org/WAI/WCAG22/Understanding/info-and-relationships.html

Teacher App

Partially Supports

Support by 1st June 2025.

Student App

Partially Supports

Support by 1st March 2025.

1.3.2. Meaningful Sequence (Level A)

Meaningful Sequence
When the sequence in which content is presented affects its meaning, a correct reading sequence can be programmatically determined.

https://www.w3.org/WAI/WCAG22/Understanding/meaningful-sequence.html

Teacher App

Supports

Student App

Supports 

1. Logical Reading Order:

The questions, options, and feedback messages are ordered in the DOM in a way that reflects the visual and intended logical sequence.

2. Keyboard Navigation:
The Tab key navigation order matches the visual flow of the quiz, ensuring that users navigating with a keyboard encounter elements in a coherent order. For example, a user can tab from the question to the answer options and then to the "Submit" button.

3. Semantic HTML:
All quiz components are built using semantic HTML to group related content programmatically.

Questions are wrapped in <fieldset> with a <legend> tag describing the question.
Answer options use <label> tags associated with their respective <input> elements.

4. Dynamic Content Updates:
Feedback or result messages are programmatically linked to the corresponding question using aria-live regions. This ensures users of assistive technologies are notified immediately when results are displayed after submitting an answer.

5. No Visual/DOM Misalignment:
The app does not rely on CSS techniques like position: absolute or order (Flexbox/Grid) to rearrange content visually, ensuring the DOM order matches the visual sequence.

6. Accessible Tables and Layouts:

When displaying scores, data tables are used with proper <thead>, <th>, and <td> elements to define relationships programmatically.

7. Screen Reader Testing:

The app has been tested with screen readers (e.g., VoiceOver), and all content is presented in the correct logical order.

8. User Guidance:

Documentation is provided to quiz creators, encouraging them to maintain logical sequences when adding custom content like images, text, or questions.

Next review period: September 2025.

1.3.3. Sensory Characteristics (Level A)

Sensory Characteristics
Instructions provided for understanding and operating content do not rely solely on sensory characteristics of components such as shape, color, size, visual location, orientation, or sound.

NOTE: For requirements related to color, refer to Guideline 1.4.

https://www.w3.org/WAI/WCAG22/Understanding/sensory-characteristics.html

Teacher App

Supports

Student App

Supports 

1. Instructions Use Clear Text Descriptions:
   Instructions for answering questions or interacting with features are text-based and do not depend solely on visual or auditory cues.
   
   Example: When a leaerner is entering a published activity, the Learner App specifies, “The test has not started.” to let the learner know that the test has not started.
   
   
2. Labels and Accessible Descriptions:
   All interactive elements, such as buttons, icons, and drag-and-drop targets, have accessible labels or descriptive text.
   
   Example: Buttons like “Start Quiz” and “Submit” are clearly labeled in text and programmatically defined using aria-label attributes where needed.
   
   
3. Color and Shape Not Sole Indicators:
   Visual indicators like color (e.g., green for correct, red for incorrect) are supplemented with text.
   
   Example: A correct answer is displayed as:
   
   
4. Text and Icon Together: e.g.“Correct! ✔”
   Screen Reader Accessible Alternative: A aria-live region announces, “Correct answer.”
   
   No Reliance on Spatial References Alone:
   
   Instructions do not use ambiguous spatial references such as “top-right corner” or “left side.” Instead, instructions specify elements by their purpose or label.
   
   Example: “Click the button labeled ‘Next’” instead of “Click the button on the right.”
   
   
5. Multiple Cues for Interactions:
   For drag-and-drop interactions, both visual and text-based cues are provided.
   
   Example: The draggable items are labeled with accessible names like “Option 1,” and targets are labeled with “Answer 1.” Screen readers announce these roles and labels during interaction.
   
   
6. Semantic HTML for Programmatic Determination:
   Semantic HTML is used for all interactive and instructional elements, ensuring screen readers and assistive technologies can interpret the relationships correctly.
   
   Example: Form elements use <label> tags associated with inputs, and buttons are defined using <button> with descriptive text.
   
   
7. Testing with Assistive Technologies:
   The app has been tested with screen readers (e.g., NVDA, JAWS, and VoiceOver), color-blindness simulators, and keyboard-only navigation to confirm compliance with this guideline.
   
   The app is designed to ensure all users, regardless of ability, can interact with it without relying on sensory characteristics alone. This includes clear and descriptive instructions, programmatically accessible labels, and multiple cues for interactions.

Next review period: September 2025.

1.4.1. Use of Color (Level A)

Use of Color
Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.

NOTE 1: This success criterion addresses color perception specifically. Other forms of perception are covered in Guideline 1.3 including programmatic access to color and other visual presentation coding.

https://www.w3.org/WAI/WCAG22/Understanding/use-of-color.html

Teacher App

Supports

Student App

Supports 

The instructor and learner app does not rely on color alone to convey meaning, ensuring accessibility for users with color vision deficiencies. All critical information is supplemented with additional indicators such as text, and /or icons.

Key functions such as activity feedback, required fields, and error messages use redundant visual cues (e.g., icons, labels) alongside color. For example, quiz answers marked with colors also include textual indicators ("Correct" or "Incorrect") with related icons ("check mark" or "x mark". Testing with color-blindness simulators and grayscale displays confirms that the app remains fully functional and accessible.

Next review period: September 2025.

1.4.2. Audio Control (Level A)

Audio Control
If any audio on a Web page plays automatically for more than 3 seconds, either a mechanism is available to pause or stop the audio, or a mechanism is available to control audio volume independently from the overall system volume level.

https://www.w3.org/WAI/WCAG22/Understanding/audio-control.html

Teacher App

Not Applicable

Student App

Not Applicable

InteDashboard complies with WCAG 1.4.2 by allowing users to attach audio files as links. These links are opened in the user’s browser, which provides accessible playback controls. The app does not auto-play audio content or directly embed audio files, ensuring that no accessibility barriers are introduced.

When instructors, teachers and staff users upload audio files to be included in activity questions, these files are linked rather than embedded. Clicking the link opens the file in the browser, where modern browsers provide accessible playback controls (e.g., play, pause, and volume adjustment). The app avoids auto-playing any audio content and ensures that the links are clearly labeled to indicate they lead to audio files. This approach delegates playback control to the browser while maintaining compliance with WCAG 1.4.2.

Next review period: September 2025.

2.1.1. Keyboard (Level A)

Keyboard
All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints.

NOTE 1: This exception relates to the underlying function, not the input technique. For example, if using handwriting to enter text, the input technique (handwriting) requires path-dependent input but the underlying function (text input) does not.

NOTE 2: This does not forbid and should not discourage providing mouse input or other input methods in addition to keyboard operation.

https://www.w3.org/WAI/WCAG22/Understanding/keyboard.html

Teacher App

Partially Supports

No upgrades planned.

Student App

Supports

InteDashboard ensures that all functionality is accessible via keyboard navigation--the learner app fully complies and the teacher app partially complies with the guideline. Students can operate all features without requiring a mouse, with logical focus order, visible focus indicators, and no keyboard traps. Additionally, alternatives are provided for any actions requiring pointer precision.

Keyboard-only functionality is not fully implemented in the following areas but only affect the TeacherApp:

• Date pickers

• Drag-drop functionalities

Next review period: September 2025.

2.1.2. No Keyboard Trap (Level A)

No Keyboard Trap
If keyboard focus can be moved to a component of the page using a keyboard interface, then focus can be moved away from that component using only a keyboard interface, and, if it requires more than unmodified arrow or tab keys or other standard exit methods, the user is advised of the method for moving focus away.

NOTE 1: Since any content that does not meet this success criterion can interfere with a user's ability to use the whole page, all content on the Web page (whether it is used to meet other success criteria or not) must meet this success criterion. See Conformance Requirement 5: Non-Interference.

https://www.w3.org/WAI/WCAG22/Understanding/no-keyboard-trap.html

Teacher App

Supports

Student App

Supports 

InteDashboard ensures that there are no keyboard traps in the interface. All elements, including modals, pop-ups, and input forms, can be accessed and navigated without keyboard restrictions, and users can freely navigate backward and forward between sections.

The following steps were taken to ensure compliance with WCAG 2.1.2:

Modals and Pop-ups: All modals (e.g., quiz creation, feedback screens) are fully navigable via the keyboard. The Tab key allows users to move between fields, and Shift + Tab allows users to go backward. Modals and pop-ups can be closed using the Esc key or a close button, which is keyboard accessible.

Focus Management: When a modal is opened, focus is immediately moved to the first focusable element inside the modal. After closing the modal, focus is returned to the element that triggered the modal (e.g., "Add Question" button).

No Keyboard Traps: Keyboard navigation was tested, and no component traps the keyboard focus. Users can always navigate freely between all sections.

Next review period: September 2025.

2.1.4. Character Key Shortcuts (Level A)

Character Key Shortcuts (Added in 2.1)
If a keyboard shortcut is implemented in content using only letter (including upper- and lower-case letters), punctuation, number, or symbol characters, then at least one of the following is true: 

Turn off: A mechanism is available to turn the shortcut off;

Remap: A mechanism is available to remap the shortcut to include one or more non-printable keyboard keys (e.g., Ctrl, Alt);

Active only on focus: The keyboard shortcut for a user interface component is only active when that component has focus.

https://www.w3.org/WAI/WCAG22/Understanding/character-key-shortcuts.html

Teacher App

Not Applicable

Student App

Not Applicable

InteDashboard does not implement any single-key keyboard shortcuts. No functionality in the app is triggered via character key shortcuts.

The app does not include single-key shortcuts for any of its functionalities. All actions and interactions are performed through mouse clicks, touch gestures, or navigable controls designed for keyboard input. As a result:

No Conflict: There are no single-key triggers to conflict with assistive technologies or accidental activations via voice input or alternative keyboards.

No Additional Settings Needed: Since shortcuts are not part of the app design, there is no need to provide options for disabling or remapping shortcuts.

Next review period: September 2025.

2.2.1. Timing Adjustable (Level A)

Timing Adjustable
For each time limit that is set by the content, at least one of the following is true: 

Turn off: The user is allowed to turn off the time limit before encountering it; or

Adjust: The user is allowed to adjust the time limit before encountering it over a wide range that is at least ten times the length of the default setting; or

Extend: The user is warned before time expires and given at least 20 seconds to extend the time limit with a simple action (for example, "press the space bar"), and the user is allowed to extend the time limit at least ten times; or

Real-time Exception: The time limit is a required part of a real-time event (for example, an auction), and no alternative to the time limit is possible; or

Essential Exception: The time limit is essential and extending it would invalidate the activity; or

20 Hour Exception: The time limit is longer than 20 hours.

https://www.w3.org/WAI/WCAG22/Understanding/timing-adjustable.html

Teacher App

Supports

Student App

Not Applicable

Due to the nature of InteDashboard as an assessment tool, only instructor users have the ability to preset, pause time limits or extend time limits.

A symbolic timer feature is available to signify time limits without consequential results for learner users.

An independent student timer feature allows instructors to provide time extensions accommodations.

Students are not provided with the ability to make adjustments to timing. This is by design for a TBL- focused product.

Next review period: September 2025.

2.2.2. Pause, Stop, Hide (Level A)

Pause, Stop, Hide
For moving, blinking, scrolling, or auto-updating information, all of the following are true:
 
Moving, blinking, scrolling: For any moving, blinking or scrolling information that (1) starts automatically, (2) lasts more than five seconds, and (3) is presented in parallel with other content, there is a mechanism for the user to pause, stop, or hide it unless the movement, blinking, or scrolling is part of an activity where it is essential; and

Auto-updating: For any auto-updating information that (1) starts automatically and (2) is presented in parallel with other content, there is a mechanism for the user to pause, stop, or hide it or to control the frequency of the update unless the auto-updating is part of an activity where it is essential.

NOTE 1: For requirements related to flickering or flashing content, refer to Guideline 2.3.

NOTE 2: Since any content that does not meet this success criterion can interfere with a user's ability to use the whole page, all content on the Web page (whether it is used to meet other success criteria or not) must meet this success criterion. See Conformance Requirement 5: Non-Interference.

NOTE 3: Content that is updated periodically by software or that is streamed to the user agent is not required to preserve or present information that is generated or received between the initiation of the pause and resuming presentation, as this may not be technically possible, and in many situations could be misleading to do so.

NOTE 4: An animation that occurs as part of a preload phase or similar situation can be considered essential if interaction cannot occur during that phase for all users and if not indicating progress could confuse users or cause them to think that content was frozen or broken.

https://www.w3.org/WAI/WCAG22/Understanding/pause-stop-hide.html

Teacher App

Not Applicable

Student App

Not Applicable

InteDashboard complies with WCAG 2.2.2 by ensuring that timers, loading animations, and redirection messages are designed to be non-distracting, brief, and essential to the app's functionality. These elements are implemented in ways that minimize user disruption and respect accessibility standards.

InteDashboard includes three components relevant to WCAG 2.2.2:

1. Countdown Timer:
The timer is an essential feature for timed quizzes, visible only to students during active tests. Teachers have full control over the timer’s behavior, including the ability to pause, stop, or hide it during quiz setup or administration. On the student side, the timer is always displayed as part of the quiz’s timed nature but is implemented with accessibility in mind, avoiding any distracting animations or blinking.

The timer functionality in the app differs for teachers and students. Teachers have control over the timer, allowing them to pause, stop, or hide it during quiz setup or live administration to manage time flexibly. For students, the timer is essential to the timed quiz experience and cannot be paused, stopped, or hidden, ensuring fairness in timed assessments. The timer is visually static and does not blink or flash, minimizing distractions. Additionally, it is accessible to assistive technologies, with screen reader compatibility ensuring that students are kept informed of remaining time through clear, periodic announcements. This design respects the essential nature of the timer for quiz functionality while meeting accessibility standards.

2. Animation for Page Transitions:
The app uses a smooth top-to-bottom wipe animation of the logo when transitioning between pages. The animation is brief (under 5 seconds) and serves as a visual indicator of loading progress. It respects user preferences for reduced motion by detecting system settings and providing a static alternative when motion is disabled.

3. Redirection Message:
When the quiz timer expires or the teacher force-ends the quiz, students see a message stating, “The test has ended. You are being redirected to the Home Screen.” This message is brief (under 5 seconds) and essential for informing students of the transition. If redirection were to take longer, a "Continue" button would be provided to allow manual progression. The message is also announced to screen readers using aria-live for assistive technology compatibility.

These features are carefully implemented to align with WCAG 2.2.2, ensuring they serve their functional purposes without unnecessary distractions or barriers for users.

Next review period: September 2025.

2.3.1. Three Flashes or Below Threshold (Level A)

Three Flashes or Below Threshold
Web pages do not contain anything that flashes more than three times in any one second period, or the flash is below the general flash and red flash thresholds.

NOTE 1: Since any content that does not meet this success criterion can interfere with a user's ability to use the whole page, all content on the Web page (whether it is used to meet other success criteria or not) must meet this success criterion. See Conformance Requirement 5: Non-Interference.

https://www.w3.org/WAI/WCAG22/Understanding/three-flashes-or-below-threshold.html

Teacher App

Not Applicable

Student App

Not Applicable

InteDashboard avoids any flashing content that exceeds the three-flashes-per-second threshold.

No Flashing Content: The app does not include any animations, images, or videos that flash more than three times per second.

Loading Animations: Smooth wipe animations are used for transitions, which do not involve flashing or blinking effects.

Student and Teacher Interfaces: Countdown timers and notifications are static or smoothly animated, avoiding any rapid changes in color or light intensity.

Next review period: September 2025.

2.4.1. Bypass Blocks (Level A)

Bypass Blocks
A mechanism is available to bypass blocks of content that are repeated on multiple Web pages.

https://www.w3.org/WAI/WCAG22/Understanding/bypass-blocks.html

Teacher App

Not Applicable

Student App

Not Applicable

InteDashboard provides mechanisms to bypass repetitive blocks of content on all pages.

Skip to Question Link: A "Skip to Question" link is present at the top of every page, allowing users to bypass navigation menus and headers and jump directly to the main content. This link is accessible via keyboard navigation and visible when focused.

ARIA Landmarks: ARIA roles (e.g., role="main", role="banner", role="navigation") are used consistently to define the structure of each page programmatically, improving navigation for screen reader users.

Quiz Page Navigation: On quiz pages, students can skip directly to the first question using the bypass feature, ensuring they don’t need to tab through navigation bars or other elements.

Next review period: September 2025.

2.4.2. Page Titled (Level A)

Page Titled
Web pages have titles that describe topic or purpose.

https://www.w3.org/WAI/WCAG22/Understanding/page-titled.html

Teacher App

Supports

Student App

Supports 

InteDashboard ensures that all pages have unique and descriptive titles.

Descriptive Titles: Each page in the app has a <title> tag with content that clearly identifies the page's purpose.

Contextual Titles for Activities: Activity pages dynamically include the quiz name and status in the title, e.g., "Science Quiz – Time Remaining: 15 Minutes," helping students and teachers track progress easily.

Error and Informational Pages: Error pages, such as "404: Page Not Found," and status pages, such as "Redirecting to XXX Page," have clear and concise titles.

Next review period: September 2025.

2.4.3. Focus Order (Level A)

Focus Order
If a Web page can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive focus in an order that preserves meaning and operability.

https://www.w3.org/WAI/WCAG22/Understanding/focus-order.html

Teacher App

Supports

Student App

Supports 

InteDashboard ensures a logical and intuitive focus order across all interactive elements.

Logical Focus Navigation: The focus order follows the visual and functional layout of the app. For instance: On quiz pages, the focus moves sequentially from the question title to answer options, navigation buttons, and the timer.

Keyboard Accessibility: All interactive elements, including buttons, links, and form fields, are focusable and navigable using the keyboard.

Dynamic Focus Management: When modals appear (e.g., for quiz submission confirmation), the focus automatically shifts to the modal. When the modal is dismissed, focus returns to the appropriate interactive element.

Error Handling: If a user attempts to submit a quiz without answering a required question, the focus shifts to the unanswered question, allowing users to address the issue efficiently.

Next review period: September 2025.

2.4.4. Link Purpose (In Context) (Level A)

Link Purpose (In Context)
The purpose of each link can be determined from the link text alone or from the link text together with its programmatically determined link context, except where the purpose of the link would be ambiguous to users in general.

https://www.w3.org/WAI/WCAG22/Understanding/link-purpose-in-context.html

Teacher App

Supports

Student App

Supports 

InteDashboard ensures that the purpose of all links is clear from their text or the surrounding context.

Descriptive Links: All links in the app are clearly labeled to indicate their purpose.

Contextual Clarity: In cases where links are embedded in a paragraph, the surrounding text provides additional context.

Link labels to user uploaded content such as attachments are at usersʼ discretion.

Next review period: September 2025.

2.5.1. Pointer Gestures (Level A)

Pointer Gestures (Added in 2.1)
All functionality that uses multipoint or path-based gestures for operation can be operated with a single pointer without a path-based gesture, unless a multipoint or path-based gesture is essential.

https://www.w3.org/WAI/WCAG22/Understanding/pointer-gestures.html

Teacher App

Not Applicable

Student App

Not Applicable

InteDashboard ensures that all critical functions can be accessed without relying on complex pointer gestures.


Avoidance of Complex Gestures: The app does not require any multi-finger or complex touch gestures for navigation or interaction. All essential functions, such as answering questions and navigating between activity pages, are accessible via simple clicks, taps, or keyboard shortcuts.

Alternatives for Complex Gestures: Where any gesture-based actions are used (e.g., swipe gestures with sliders, drag and drop), alternative methods like buttons and keyboard navigation are provided to ensure that users with motor disabilities can still interact with the app effectively.

Next review period: September 2025.

2.5.2. Pointer Cancellation (Level A)

Pointer Cancellation (Added in 2.1)
For functionality that can be operated using a single pointer, at least one of the following is true:

No Down-Event: The down-event of the pointer is not used to execute any part of the function;

Abort or Undo: Completion of the function is on the up-event, and a mechanism is available to abort the function before completion or to undo the function after completion;

Up Reversal: The up-event reverses any outcome of the preceding down-event;

Essential: Completing the function on the down-event is essential.

https://www.w3.org/WAI/WCAG22/Understanding/pointer-cancellation.html

Teacher App

Supports

Student App

Supports 

InteDashboard ensures that users can cancel or undo actions triggered by pointer events.

Cancellation of Critical Actions: InteDashboard allows users to cancel or undo critical actions. For example, if a learner accidentally clicks the "Submit Quiz" button, they are prompted with a confirmation message: "Are you sure you want to submit your answers?" This prevents accidental submission. This is similarly implemented in the Instructor app, where critical actions are prompted to confirm them.

Confirmation for Irreversible Actions: Any irreversible actions, such as deleting a question, are preceded by a clear confirmation dialog that gives users the option to cancel.

Time-based Events: The timer can be paused or stopped by the instructor if necessary, and clear feedback is provided to learners if the timer is paused or reset. Learners also have a visible timer countdown, which can be stopped by the teacher at any time.

Undoing Selections: Learners Students are able to unselect or change their selections and are prompted to "save their answer" to commit their answer to a question.

Next review period: September 2025.

2.5.3. Label in Name (Level A)

Label in Name (Added in 2.1)
For user interface components with labels that include text or images of text, the name contains the text that is presented visually.

https://www.w3.org/WAI/WCAG22/Understanding/label-in-name.html

Teacher App

Partially Supports

Support by 1st March 2025.

Student App

Supports

InteDashbaord ensures that all user interface components with labels have consistent accessible names that match their visual labels.

Label and Accessible Name Consistency: Every button, form field, and interactive element in the app has a label that is both visually clear and programmatically defined for assistive technologies. For example, the button labeled “Submit Quiz” is also given the accessible name “Submit Quiz,” ensuring it is announced consistently by screen readers.

Icons as Interactive Controls: The app uses icons for certain actions, such as a pencil for editing questions. These icons have been assigned descriptive aria-label attributes (e.g., aria-label="Edit Question"), ensuring that users relying on screen readers understand the action being performed.

Form Field Labels: Input fields, such as “Enter Your Name,” are clearly labeled both visually and with an accessible name, ensuring consistency between what is presented on the screen and what is conveyed to assistive technologies.

Clear and Descriptive Feedback: All status changes, such as marking a question as answered or skipped, are announced with consistent, descriptive labels, ensuring that users with assistive technologies are informed of the changes.

All features in the Instructor app marked as "beta" partially complies with this guideline and will be rectified.

Next review period: September 2025.

2.5.4. Motion Actuation (Level A)

Motion Actuation (Added in 2.1)
Functionality that can be operated by device motion or user motion can also be operated by user interface components and responding to the motion can be disabled to prevent accidental actuation, except when:

Supported Interface: The motion is used to operate functionality through an accessibility supported interface;

Essential: The motion is essential for the function and doing so would invalidate the activity.

https://www.w3.org/WAI/WCAG22/Understanding/captions-prerecorded.html

Teacher App

Not Applicable

Student App

Not Applicable

InteDashboard does not using any motion-based interactions. All actions within the both the instructor and learner app are initiated through accessible methods such as buttons and touch gestures, ensuring no reliance on motion input.

No Motion-based Actions: Neither the teacher nor the student app utilizes motion-based inputs (such as shaking, tilting, or rotating the device) for any key actions. All core functionality, such as submitting quizzes, navigating through questions, or starting/stopping the quiz, is controlled through traditional methods such as buttons or swipe gestures.

Accessible Alternatives: Since there are no motion-based interactions, there is no need to provide alternative methods for performing actions based on motion.

User Control Over Motion: As the app does not include motion-based inputs, users are not required to engage with any motion-related interactions. All actions are fully accessible using touch, button controls, and standard user interface elements.

Next review period: September 2025.

3.1.1. Language of Page (Level A)

Language of Page
The default human language of each Web page can be programmatically determined.

https://www.w3.org/WAI/WCAG22/Understanding/language-of-page.html

Teacher App

Supports

Student App

Supports 

InteDashboard complies with WCAG 3.1.1 by correctly identifying the language of content, including content input by teachers in languages other than the default language (English). The primary language of the app is English, and any content in other languages is programmatically identified with the appropriate lang attribute.

Primary Language of the App: The app’s default language is English, with the lang="en" attribute in the <html> tag.

Teacher Input in Other Languages: When teachers input content in other languages (e.g., Spanish or French), each piece of content is marked with the appropriate lang attribute. For instance, a question in Spanish will use lang="es" to specify the language.

Dynamic Content Handling: The app ensures that if content changes languages dynamically (e.g., based on a teacher's input), the lang attribute is updated to reflect the correct language for each section or content block.

Next review period: September 2025.

3.2.1. On Focus (Level A)

On Focus
When any user interface component receives focus, it does not initiate a change of context.

https://www.w3.org/WAI/WCAG22/Understanding/on-focus.html

Teacher App

Supports

Student App

Supports 

The app partially complies with WCAG 3.2.1. While most interactive elements behave predictably, the "Save My Answer" button in the student interface triggers a context change by moving to the next question without prior user awareness.

Predictable Behavior: Most buttons and controls in the app do not cause changes in context when focused or clicked unless explicitly triggered by the user.
For example, navigation between sections, submitting answers, and interacting with dropdowns require explicit user input.

Issue with "Save My Answer" Button: Clicking the "Save My Answer" button automatically advances the user to the next question. This action is not fully compliant with WCAG 3.2.1 as it causes a context change without prior notification or explicit user consent.

Planned Updates: Future updates will improve compliance by either:

Clearly labeling the button (e.g., "Save and Go to Next Question").

Providing a separate "Save Answer" button without automatic navigation.

Adding a clear feedback of the saved answer before advancing to the next question.

This ensures users have better control over navigation and improves accessibility for keyboard users and assistive technology users.

Next review period: September 2025.

3.2.2. On Input (Level A)

On Input
Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behavior before using the component.

https://www.w3.org/WAI/WCAG22/Understanding/on-input.html

Teacher App

Supports

Student App

Supports 

InteDashboard demonstrates partial compliance with WCAG 3.2.2. Automatic context changes, such as screen redirection when the timer runs out, the teacher ends the quiz, or during discussion sessions, are implemented predictably. Additional steps can be taken to ensure users are explicitly notified of these behaviors beforehand to enhance accessibility.

Timer End Behavior: When the quiz timer expires, students are automatically redirected to the start screen. This behavior is consistent and expected, as users are informed that quizzes are timed and their session ends when the timer runs out.

Teacher-Controlled Actions: The teacher can force-end activities or direct students to specific question screens during discussions. These changes align with the app's intended functionality but require clear, upfront communication to ensure students understand and anticipate such behavior.

Predictability and Notifications: While the app ensures these automatic actions occur predictably, providing explicit notifications or instructions (e.g., "When the timer ends, you will be redirected" or "Your screen may follow the teacher during discussions") further enhances compliance with this guideline.

Planned Updates: Future updates will improve compliance by:

Providing clear instructions and notifications to students about these automatic behaviors. "During discussions, your screen will automatically follow the teacher's navigation."

Next review period: September 2025.

3.2.6. Consistent Help (Level A)

Consistent Help (Added in 2.2)
If a Web page contains any of the following help mechanisms, and those mechanisms are repeated on multiple Web pages within a set of Web pages, they occur in the same order relative to other page content, unless a change is initiated by the user:

Human contact details;

Human contact mechanism;

Self-help option;

A fully automated contact mechanism.

Note 1: A fully automated contact mechanism.

NOTE 2: For this Success Criterion, “the same order relative to other page content” can be thought of as how the content is ordered when the page is serialized. The visual position of a help mechanism is likely to be consistent across pages for the same page variation (e.g., CSS break-point). The user can initiate a change, such as changing the page’s zoom or orientation, which may trigger a different page variation. This criterion is concerned with relative order across pages displayed in the same page variation (e.g., same zoom level and orientation).

https://www.w3.org/WAI/WCAG22/Understanding/consistent-help.html

Teacher App

Supports

Student App

Supports 

InteDashboard fully complies with WCAG 3.2.6 by maintaining consistent navigation mechanisms and structure across all pages of both the teacher and student interfaces.

Uniform Navigation Bar: Both the teacher and student apps feature a fixed navigation bar that retains the same structure, order, and location across all screens. For instance, the student app consistently displays links to "Dashboard," "Activities," and "Grades" in the same sequence.

Consistent Terminology and Icons: Terms like "Add New Course" and "View Results" in the teacher app, and "Enter Activity" and "View Answers" in the student app, are consistently labeled across screens. Icons accompanying these terms also remain uniform.

Standard Page Layouts: Pages maintain a consistent layout, ensuring navigational elements such as breadcrumbs, sidebars, and footers are in the same position and style across the app.

Predictable User Flow: Whether a user navigates through the app’s dashboard, quiz screens, or result pages, the placement and functionality of navigation mechanisms remain predictable, enhancing usability and accessibility.

Periodic Reviews: Regular testing ensures no discrepancies or inconsistencies in navigation elements are introduced during updates or new feature implementations.

Next review period: September 2025.

3.3.1. Error Identification (Level A)

Error Identification
If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text.

https://www.w3.org/WAI/WCAG22/Understanding/error-identification.html

Teacher App

Supports

Student App

Supports 

InteDashboard fully complies with WCAG 3.3.1 by effectively identifying and describing errors when they occur in user input fields. The app also ensures that these errors are easily understandable and accessible to all users.

Error Detection and Messages: In the learner app, when a user leaves a required field blank, a clear error message such as “Please answer this question before submitting” or “Invalid input. Please enter a valid answer.” is displayed next to the relevant question.

Location and Focus of Errors: The error messages are placed immediately below the relevant input field or button. The app also shifts focus to the error message so the user can correct it easily.

ARIA Live Regions for Screen Readers: Inte Dashboard uses ARIA live regions to ensure that screen reader users are promptly notified of the error message.

Consistent Error Feedback: Whether in the teacher or student app, error identification follows the same consistent pattern: an error message, clear description, and focus shift, ensuring all users can resolve the issue quickly.

Next review period: September 2025.

3.3.2. Labels or Instructions (Level A)

Labels or Instructions
Labels or instructions are provided when content requires user input.

https://www.w3.org/WAI/WCAG22/Understanding/labels-or-instructions.html

Teacher App

Supports

Student App

Supports 

InteDashboard partially complies with WCAG 3.3.2 as clear labels and instructions are provided for most interactive elements and form fields, though there are areas within the teacher app that lack full instructional text or detailed guidance for more complex fields.

Clear Labels for Input Fields: The instructor app includes clear labels for many form fields. For example, when creating an activity, fields like "Enter activity name" and "Select activity type" are clearly labeled, helping users understand what information is required.

Descriptive Instructions for Complex Fields (Partial Compliance): While the learner app provides clear instructions for certain input types (e.g., numeric answers), the instructor app has some areas where instructional text is missing. For instance, when the teacher uploads a media file for a question stem, the app lacks explicit instructions on file formats or size limitations.

Instructional Text for Formatting (Partial Compliance): While instructional text is provided in some areas (e.g., multiple-choice question formats), other complex input fields (e.g., file uploads, question stem formatting) do not include sufficient guidance or examples for instructors to follow.

Field Proximity and Consistency: Labels are consistently placed near their associated input fields, both for the instructor and learner apps, ensuring the information is accessible.

Helpful Error Instructions: In the learner app, error messages are provided when learners leave questions unanswered, but the instructor app lacks comprehensive error messages and instructional text in some cases, which may make error resolution less intuitive for users.

Next review period: September 2025.

4.1.1. Parsing (Level A)

Parsing

Teacher App

Supports

Student App

Supports 

InteDashboard is developed using valid HTML, ensuring that all interactive and content elements are properly structured and free from syntax errors. The app follows best practices for parsing, maintaining valid nesting of elements, unique IDs, and correct attribute usage. Some elements in isolated sections lack programmatic association with the visual label, or states not indicated. These currently affect only the Teacher App are are on screens that are used by a minority of users, e.g. Super Admins.

Next review period: September 2025.

4.1.2. Name, Role, Value (Level A)

Name, Role, Value
For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies.

NOTE 1: This success criterion is primarily for Web authors who develop or script their own user interface components. For example, standard HTML controls already meet this success criterion when used according to specification.

https://www.w3.org/WAI/WCAG22/Understanding/name-role-value.html

Teacher App

Partially Supports

No upgrades planned

Student App

Supports

InteDashboard ensures that all interactive elements, such as buttons, form fields, and navigation controls, have clear names, roles, and values that can be recognized by assistive technologies. The app follows ARIA best practices where necessary to enhance accessibility.

InteDashboard appropriate programmatic labels and roles for all interactive components. Buttons (e.g., "Submit Answer," "Next Question"), form fields, and navigation elements have explicit labels and ARIA attributes where needed. Dynamic elements, such as quiz questions and interactive controls, correctly expose their current state to assistive technologies. Additionally, when users interact with quiz components (e.g., selecting an answer or submitting a response), changes in value and status are properly conveyed to screen readers and other assistive tools.

Next review period: September 2025.

1.2.4 Captions (Live) (Level AA)

Also applies to:

EN 301 549 Criteria

●     9.1.2.4 (Web)

●     10.1.2.4 (Non-web document)

●     11.1.2.4 (Open Functionality Software)

●     11.1.2.4 (Closed Software)

●     11.8.2 (Authoring Tool)

●     12.1.2 (Product Docs)

●     12.2.4 (Support Docs)

Revised Section 508

●     501 (Web)(Software)

●     504.2 (Authoring Tool)

●     602.3 (Support Docs)

Teacher App

Not Applicable

Student App

Not Applicable

InteDashboard does not contain live media, however instructor users can upload their own media that can be audio-only or video-only. It is the responsibility of users to provide closed captioning for any audio content in synchronized media.

Next review period: March/April 2025.

1.2.5 Audio Description (Prerecorded) (Level AA)

Also applies to:

EN 301 549 Criteria

●     9.1.2.5 (Web)

●     10.1.2.5 (Non-web document)

●     11.1.2.5 (Open Functionality Software)

●     11.1.2.5 (Closed Software)

●     11.8.2 (Authoring Tool)

●     12.1.2 (Product Docs)

●     12.2.4 (Support Docs)

Revised Section 508

●     501 (Web)(Software)

●     504.2 (Authoring Tool)

●     602.3 (Support Docs)

Teacher App

Not Applicable

Student App

Not Applicable

InteDashboard does not contain pre-recorded audio media, however instructor users can upload their own media. It is the responsibility of users to select an accessible media player for their content.

Next review period: March/April 2025.

1.3.4 Orientation (Level AA 2.1 only)

Also applies to:

EN 301 549 Criteria

●     9.1.3.4 (Web)

●     10.1.3.4 (Non-web document)

●     11.1.3.4 (Open Functionality Software)

●     11.1.3.4 (Closed Software)

●     11.8.2 (Authoring Tool)

●     12.1.2 (Product Docs)

●     12.2.4 (Support Docs)

Revised Section 508 – Does not apply

Teacher App

Supports

Student App

Supports 

The Teacher App must be used in landscape mode on a tablet/desktop device.

Next review period: March/April 2025.

1.3.5 Identify Input Purpose (Level AA 2.1 only)

Also applies to:

EN 301 549 Criteria

●     9.1.3.5 (Web)

●     10.1.3.5 (Non-web document)

●     11.1.3.5.1 (Open Functionality Software)

●     11.1.3.5.2 (Closed Software)

●     11.8.2 (Authoring Tool)

●     12.1.2 (Product Docs)

●     12.2.4 (Support Docs)

Revised Section 508 – Does not apply

Teacher App

Supports

Student App

Supports 

All form inputs have either a visual label or are programmatically associated wherever possible. 

Next review period: March/April 2025.

1.4.3 Contrast (Minimum) (Level AA)

Also applies to:

EN 301 549 Criteria

●     9.1.4.3 (Web)

●     10.1.4.3 (Non-web document)

●     11.1.4.3 (Open Functionality Software)

●     11.1.4.3 (Closed Software)

●     11.8.2 (Authoring Tool)

●     12.1.2 (Product Docs)

●     12.2.4 (Support Docs)

Revised Section 508

●     501 (Web)(Software)

●     504.2 (Authoring Tool)

●     602.3 (Support Docs)

Teacher App

Partially Supports

No upgrades planned

Student App

Supports

We have progressively updated most UI elements such as radio buttons, checkboxes, toggle buttons and status tags in accordance with an accessible design system.

Next review period: March/April 2025.

1.4.4 Resize text (Level AA)

Also applies to:

EN 301 549 Criteria

●     9.1.4.4 (Web)

●     10.1.4.4 (Non-web document)

●     11.1.4.4.1 (Open Functionality Software)

●     11.1.4.4.2 (Closed Software)

●     11.8.2 (Authoring Tool)

●     12.1.2 (Product Docs)

●     12.2.4 (Support Docs)

Revised Section 508

●     501 (Web)(Software)

●     504.2 (Authoring Tool)

●     602.3 (Support Docs)

Teacher App

Supports

Student App

Supports 

Resize text functionality is provided for both learner and instructor users on the dashboard. 

Next review period: March/April 2025.

1.4.5 Images of Text (Level AA)

Also applies to:

EN 301 549 Criteria

●     9.1.4.5 (Web)

●     10.1.4.5 (Non-web document)

●     11.1.4.5.1 (Open Functionality Software)

●     11.1.4.5.2 (Closed Software) – Does not apply

●     11.8.2 (Authoring Tool)

●     12.1.2 (Product Docs)

●     12.2.4 (Support Docs)

Revised Section 508

●     501 (Web)(Software)

●     504.2 (Authoring Tool)

●     602.3 (Support Docs)

Teacher App

Supports

Student App

Supports 

By default, there are no images of text in InteDashboard. 

Instructor users have the ability to upload their own content. It is the user’s responsibility to make sure their content is accessible.

Next review period: March/April 2025.

1.4.10 Reflow (Level AA 2.1 only)

Also applies to:

EN 301 549 Criteria

●     9.1.4.10 (Web)

●     10.1.4.10 (Non-web document)

●     11.1.4.10 (Open Functionality Software)

●     11.1.4.10 (Closed Software)

●     11.8.2 (Authoring Tool)

●     12.1.2 (Product Docs)

●     12.2.4 (Support Docs)

Revised Section 508 – Does not apply

Teacher App

Partially Supports

No upgrades planned

Student App

Supports

InteDashboard supports screen resize to 200%, however the layout of components in some pages are not yet ideal.

Next review period: March/April 2025.

1.4.11 Non-text Contrast (Level AA 2.1 only)

Also applies to:

EN 301 549 Criteria

●     9.1.4.11 (Web)

●     10.1.4.11 (Non-web document)

●     11.1.4.11 (Open Functionality Software)

●     11.1.4.11 (Closed Software)

●     11.8.2 (Authoring Tool)

●     12.1.2 (Product Docs)

●     12.2.4 (Support Docs)

Revised Section 508 – Does not apply

Teacher App

Not Applicable

Student App

Not Applicable

InteDashboard does not contain non-text content that affects text contrast.

Next review period: March/April 2025.

1.4.12 Text Spacing (Level AA 2.1 only)

Also applies to:

EN 301 549 Criteria

●     9.1.4.12 (Web)

●     10.1.4.12 (Non-web document)

●     11.1.4.12 (Open Functionality Software)

●     11.1.4.12 (Closed Software)

●     11.8.2 (Authoring Tool)

●     12.1.2 (Product Docs)

●     12.2.4 (Support Docs)

Revised Section 508 – Does not apply

Teacher App

Supports

Student App

Supports 

Basic text resizing is available.

Next review period: March/April 2025.

1.4.13 Content on Hover or Focus (Level AA 2.1 only)

Also applies to:

EN 301 549 Criteria

●     9.1.4.13 (Web)

●     10.1.4.13 (Non-web document)

●     11.1.4.13 (Open Functionality Software)

●     11.1.4.13 (Closed Software)

●     11.8.2 (Authoring Tool)

●     12.1.2 (Product Docs)

●     12.2.4 (Support Docs)

Revised Section 508 – Does not apply

Teacher App

Supports

Student App

Supports 

Drop boxes or combo boxes in InteDashboard require selection to appear and are persistent and dismissable with the Esc key.

Next review period: March/April 2025.

2.4.5 Multiple Ways (Level AA)

Also applies to:

EN 301 549 Criteria

●     9.2.4.5 (Web)

●     10.2.4.5 (Non-web document) – Does not apply

●     11.2.4.5 (Open Functionality Software) – Does not apply

●     11.2.4.5 (Closed Software) – Does not apply

●     11.8.2 (Authoring Tool)

●     12.1.2 (Product Docs)

●     12.2.4 (Support Docs)

Revised Section 508

●     501 (Web)(Software) – Does not apply to non-web software

●     504.2 (Authoring Tool)

●     602.3 (Support Docs) – Does not apply to non-web docs

Teacher App

Supports

Student App

Supports 

Yes, multiple ways to access content exist. They are designed for intuitiveness, not just to conform to this standard.

For instance, to view or edit a question you can either go to the Question Bank or to a Course > Module > Activity > Question. Multiple tabs which allow Instructor users to navigate between activities in a course are also available.

Next review period: March/April 2025.

2.4.6 Headings and Labels (Level AA)

Also applies to:

EN 301 549 Criteria

●     9.2.4.6 (Web)

●     10.2.4.6 (Non-web document)

●     11.2.4.6 (Open Functionality Software)

●     11.2.4.6 (Closed Software)

●     11.8.2 (Authoring Tool)

●     12.1.2 (Product Docs)

●     12.2.4 (Support Docs)

Revised Section 508

●     501 (Web)(Software)

●     504.2 (Authoring Tool)

●     602.3 (Support Docs)

Teacher App

Partially Supports

No upgrades planned

Student App

Supports

Headings and labels sufficiently describe topic or purpose of some sections.

Next review period: March/April 2025.

2.4.7 Focus Visible (Level AA)

Also applies to:

EN 301 549 Criteria

●     9.2.4.7 (Web)

●     10.2.4.7 (Non-web document)

●     11.2.4.7 (Open Functionality Software)

●     11.2.4.7 (Closed Software)

●     11.8.2 (Authoring Tool)

●     12.1.2 (Product Docs)

●     12.2.4 (Support Docs)

Revised Section 508

●     501 (Web)(Software)

●     504.2 (Authoring Tool)

●     602.3 (Support Docs)

Teacher App

Partially Supports

No upgrades planned

Student App

Supports

When using the keyboard for navigation, either via the Tab key or the arrow keys, focused elements on the screen will have an obvious border of at least 2px.

Next review period: March/April 2025.

3.1.2 Language of Parts (Level AA)

Also applies to:

EN 301 549 Criteria

●     9.3.1.2 (Web)

●     10.3.1.2 (Non-web document)

●     11.3.1.2 (Open Functionality Software) – Does not apply

●     11.3.1.2 (Closed Software) – Does not apply

●     11.8.2 (Authoring Tool)

●     12.1.2 (Product Docs)

●     12.2.4 (Support Docs)

Revised Section 508

●     501 (Web)(Software)

●     504.2 (Authoring Tool)

●     602.3 (Support Docs)

Teacher App

Not Applicable

Student App

Not Applicable

InteDashboard is currently only available in English.

Next review period: March/April 2025.

3.2.3 Consistent Navigation (Level AA)

Also applies to:

EN 301 549 Criteria

●     9.3.2.3 (Web)

●     10.3.2.3 (Non-web document) – Does not apply

●     11.3.2.3 (Open Functionality Software) – Does not apply

●     11.3.2.3 (Closed Software) – Does not apply

●     11.8.2 (Authoring Tool)

●     12.1.2 (Product Docs)

●     12.2.4 (Support Docs)

Revised Section 508

●     501 (Web)(Software) – Does not apply to non-web software

●     504.2 (Authoring Tool)

●     602.3 (Support Docs) – Does not apply to non-web docs

Teacher App

Supports

Student App

Supports 

Navigation is consistent across UI elements, and a navigation bar allows users a standard way to move across sections.

Next review period: March/April 2025.

3.2.4 Consistent Identification (Level AA)

Also applies to:

EN 301 549 Criteria

●     9.3.2.4 (Web)

●     10.3.2.4 (Non-web document) – Does not apply

●     11.3.2.4 (Open Functionality Software) – Does not apply

●     11.3.2.4 (Closed Software) – Does not apply

●     11.8.2 (Authoring Tool)

●     12.1.2 (Product Docs)

●     12.2.4 (Support Docs)

Revised Section 508

●     501 (Web)(Software) – Does not apply to non-web software

●     504.2 (Authoring Tool)

●     602.3 (Support Docs) – Does not apply to non-web docs

Teacher App

Supports

Student App

Supports 

Components that have the same functionality within a set of Web pages are identified consistently. 

Next review period: March/April 2025.

3.3.3 Error Suggestion (Level AA)

Also applies to:

EN 301 549 Criteria

●     9.3.3.3 (Web)

●     10.3.3.3 (Non-web document)

●     11.3.3.3 (Open Functionality Software)

●     11.3.3.3 (Closed Software)

●     11.8.2 (Authoring Tool)

●     12.1.2 (Product Docs)

●     12.2.4 (Support Docs)

Revised Section 508

●     501 (Web)(Software)

●     504.2 (Authoring Tool)

●     602.3 (Support Docs)

Teacher App

Supports

Student App

Supports 

When errors occur, the user is directed through text instructions on how to correct the error.

Next review period: March/April 2025.

3.3.4 Error Prevention (Legal, Financial, Data) (Level AA)

Also applies to:

EN 301 549 Criteria

●     9.3.3.4 (Web)

●     10.3.3.4 (Non-web document)

●     11.3.3.4 (Open Functionality Software)

●     11.3.3.4 (Closed Software)

●     11.8.2 (Authoring Tool)

●     12.1.2 (Product Docs)

●     12.2.4 (Support Docs)

Revised Section 508

●     501 (Web)(Software)

●     504.2 (Authoring Tool)

●     602.3 (Support Docs)

Teacher App

Supports

Student App

Supports 

For critical actions such as deletion, a warning is always presented to the user before they commit the action. 

Next review period: March/April 2025.

4.1.3 Status Messages (Level AA 2.1 only)

Also applies to:

EN 301 549 Criteria

●     9.4.1.3 (Web)

●     10.4.1.3 (Non-web document)

●     11.4.1.3 (Open Functionality Software)

●     11.4.1.3 (Closed Software) – Does not apply

●     11.8.2 (Authoring Tool)

●     12.1.2 (Product Docs)

●     12.2.4 (Support Docs)

Revised Section 508 – Does not apply

Teacher App

Partially Supports

No upgrades planned

Student App

Supports

Status message notifications exist in InteDashboard, and announce alerts or changes to the user. 

The use of aria-live for activity timers has been implemented.

Next review period: March/April 2025.

504 Authoring Tools

504.2 Content Creation or Editing (if not authoring tool, enter “not applicable”)

See WCAG 2.1 section

See information in WCAG 2.1 section

504.2.1 Preservation of Information Provided for Accessibility in Format Conversion

Teacher App

Not Applicable

Student App

Not Applicable

Next review period: June 2025.

504.2.2 PDF Export

Teacher App

Does Not Support

Student App

Does Not Support

New features are currently being develop to support users of IF-AT cards which will require the ability to export questions to a PDF.

Next review period: June 2025.

504.3 Prompts

Teacher App

Does Not Support

Student App

Does Not Support

Currently there are no prompts for users to improve the accessibility of their content. However, we hope to include these in later by implementing third-party accessibility apps.

Next review period: June 2025.

504.4 Templates

Not Applicable

601.1 Scope

Heading cell – no response required

Heading cell – no response required

602 Support Documentation

602.2 Accessibility and Compatibility Features

Does Not Support

602.3 Electronic Support Documentation

See WCAG 2.1 section

See information in WCAG 2.x section

602.4 Alternate Formats for Non-Electronic Support Documentation

Teacher App

Not Applicable

Student App

Not Applicable

All necessary documentation for InteDashboard is provided electronically.

603 Support Services

603.2 Information on Accessibility and Compatibility Features

Teacher App

Supports

Student App

Supports 

The support team at InteDashboard can provide information about accessibility features of the product.

Next review period: June 2025.

603.3 Accommodation of Communication Needs

Teacher App

Supports

Student App

Supports 

All communication is available via electronic means such as email.

Next review period: June 2025.

11.0 General (informative)

11.1.1.1 through 11.4.1.3

-

See information in WCAG 2.1 section.

11.5 Interoperability with assistive technology

11.5.1 Closed functionality

11.5.2 Accessibility services

11.5.2.1 Platform accessibility service support for software that provides a user interface

See 11.5.2.5 through 11.5.2.17

See information in 11.5.2.5 through 11.5.2.17

11.5.2.2 Platform accessibility service support for assistive technologies

See 11.5.2.5 through 11.5.2.17

See information in 11.5.2.5 through 11.5.2.17

11.5.2.3 Use of accessibility services

Teacher App

Supports

Student App

Supports 

InteDashboard uses standard platform accessibility services.

Next review period: June 2025.

11.5.2.4 Assistive technology

Teacher App

Not Applicable

Student App

Not Applicable

InteDashboard is not an assistive technology.

Next review period: June 2025.

11.5.2.5 Object information

Teacher App

Partially Supports

No upgrades planned

Student App

Partially Supports

Full support by 1 Jan '25

Most components have accessible names, roles and values

Next review period: June 2025.

11.5.2.6 Row, column, and headers

Teacher App

Partially Supports

No upgrades planned

Student App

Partially Supports

Full support by 1 Jan '25

Layout tables are currently used in InteDashboard to organize content. This will be rectified to HTML best practices in later releases of the app.

Next review period: June 2025.

11.5.2.7 Values

Teacher App

Supports

Student App

Supports 

Most error and warning values have visual indication but and are screen reader compatible.

Next review period: June 2025.

11.5.2.8 Label relationships

Teacher App

Partially Supports

No upgrades planned

Student App

Partially Supports

Full support by 1 Jan '25

Most components have ARIA labels or are associated with their visible labels.

Next review period: June 2025.

11.5.2.9 Parent-child relationships

Teacher App

Supports

Student App

Supports 

Nested HTML relationships are used

Next review period: June 2025.

11.5.2.10 Text

Teacher App

Supports

Student App

Supports 

 Next review period: June 2025.

11.5.2.11 List of available actions

Teacher App

Supports

Student App

Supports 

 Next review period: June 2025.

11.5.2.12 Execution of available actions

Teacher App

Supports

Student App

Supports 

 Next review period: June 2025.

11.5.2.13 Tracking of focus and selection attributes

Teacher App

Partially Supports

No upgrades planned

Student App

Partially Supports

Full support by 1 Jan '25

Layout tables are currently used in InteDashboard to organise content. Due to the design of the app, this currently does not preset any issues. We intend to shift the student-facing interface into native iOS and Android.

Next review period: June 2025.

11.5.2.14 Modification of focus and selection attributes

Does Not Support

11.5.2.15 Change notification

Teacher App

Supports

Student App

Supports 

Status Message notifications announce changes or alerts. 

Next review period: June 2025.

11.5.2.16 Modifications of states and properties

Teacher App

Does Not Support

Student App

Does Not Support

We may have features lined up in 2025 that will require full or partial support.

Next review period: June 2025.

11.5.2.17 Modifications of values and text

Teacher App

Does Not Support

Student App

Does Not Support

 We may have features lined up in 2025 that will require full or partial support.

Next review period: June 2025.

11.6 Documented accessibility usage

11.6.1 User control of accessibility features

Teacher App

Not Applicable

Student App

Not Applicable

InteDashboard is not considered platform software as defined by EN 301 549.

Next review period: June 2025.

11.6.2 No disruption of accessibility features

Teacher App

Supports

Student App

Supports 

 Next review period: June 2025.

11.7 User preferences

Teacher App

Supports

Student App

Supports 

The product respects user preferences from platform or OS settings.

Next review period: June 2025.

11.8 Authoring tools

11.8.1 Content technology

11.8.2 Accessible content creation

-

See information in WCAG 2.1 section.

11.8.3 Preservation of accessibility information in transformations

-

See information in WCAG 2.1 section.

11.8.4 Repair assistance

-

See information in WCAG 2.1 section.

11.8.5 Templates

-

See information in WCAG 2.1 section.

12.1 Product documentation

12.1.1 Accessibility and compatibility features

Teacher App

Evolving Support

Student App

Evolving Support

Our user guides are created quickly by our Customer Success Team so that most users can take advantage of the content. Our accessibility conformance web-developer(s) update these as bandwidth becomes available. 

Next review period: June 2025.

12.1.2 Accessible documentation

-

See information in WCAG 2.1 section.

12.2 Support Services

12.2.2 Information on accessibility and compatibility features

Teacher App

Supports

Student App

Supports 

Our Customer Success Team can provide more information about accessibility features of the product. More detailed enquiries can be escalated to our Product Team.

Next review period: June 2025.

12.2.3 Effective communication

Teacher App

Evolving Support

Student App

Evolving Support

Our user guides are created quickly by our Customer Success Team so that most users can take advantage of the content. As we receive feedback from users, we evolve these to ensure all audiences are supported.

Next review period: June 2025.

12.2.4 Accessible documentation

-

See information in WCAG 2.1 section.