Our Commitment to Accessibility

Web Content Accessibility Guidelines 2.2

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.

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.

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 2.2 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.

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.

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.

Teacher App

Supports

Student App

Supports

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.

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.

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.

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.

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.

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.

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.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
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.

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.

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.

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.

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.

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.

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.

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.

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
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.

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
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.

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
For user interface components with labels that include text or images of text, the name contains the text that is presented visually.

Teacher App

Partially Supports

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
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.

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.

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.

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.

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).

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.

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.

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.

Teacher App

Partially Supports

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)
Captions are provided for all live audio content in synchronized media.

Teacher App

Not Applicable

Student App

Not Applicable

InteDashboard does not feature any live audio or video content. Since InteDashboard does not include live events or broadcasts that feature real-time audio content, this guideline does not apply. However, for any future live events or audio content, InteDashboard will ensure compliance with WCAG 1.2.4 by providing live captions or offering alternative accessible formats.

1.2.5 Audio Description (Prerecorded)
Audio description is provided for all prerecorded video content in synchronized media.

Teacher App

Not Applicable

Student App

Not Applicable

InteDashboard allows users to upload prerecorded videos. While InteDshboard does not provide audio descriptions by default, it encourages activity creators and authors to add audio descriptions for videos with important visual elements.

• No Native Video Content: InteDasboard itself does not provide prerecorded videos that require audio descriptions.
• User Responsibility: When instructors, teachers and staff users upload prerecorded videos that contain visual content, InteDashboard provides the facility for users to provide audio descriptions to meet accessibility guidelines.

1.3.4 Orientation
Content does not restrict its view and operation to a single display orientation, such as portrait or landscape, unless a specific display orientation is essential.

NOTE: Examples where a particular display orientation may be essential are a bank check, a piano application, slides for a projector or television, or virtual reality content where content is not necessarily restricted to landscape or portrait display orientation.

Teacher App

Supports

Student App

Supports 

InteDashboard supports both portrait and landscape orientations across all supported devices, ensuring full functionality and accessibility regardless of device orientation for both the teacher and learner apps.

InteDashboard is designed to dynamically adjust its layout and functionality based on the user’s preferred orientation. Whether the user holds their smartphone or tablet in portrait or landscape mode, the content, including quiz questions, answers, and interactive elements, remains fully visible and operational without requiring manual rotation.

For laptop and desktop users, InteDashboard seamlessly adapts to landscape displays while maintaining compatibility with vertical monitors or assistive technology setups requiring portrait orientation.

Additionally, InteDashboard does not enforce a specific orientation unless it is essential to the function of a feature.

This approach ensures usability for a broad audience, including individuals who rely on fixed device mounts or assistive technologies that limit orientation flexibility.

1.3.5 Identify Input Purpose
The purpose of each input field collecting information about the user can be programmatically determined when:

• The input field serves a purpose identified in the Input Purposes for user interface components section; and
• The content is implemented using technologies with support for identifying the expected meaning for form input data.

Teacher App

Supports

Student App

Supports 

All input fields in InteDashboard for both instructor and learner app include programmatically determinable purposes using standardized attributes, ensuring compatibility with assistive technologies and autofill capabilities.

InteDashboard leverages the autocomplete attribute for input fields such as name, email, and payment information. This allows assistive technologies to correctly identify the purpose of each field, enabling users with disabilities to complete forms efficiently. Testing with screen readers and autofill tools confirms proper functionality.

1.4.3 Contrast (Minimum)
The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except for the following:

• Large Text: Large-scale text and images of large-scale text have a contrast ratio of at least 3:1;
• Incidental: Text or images of text that are part of an inactive user interface component, that are pure decoration, that are not visible to anyone, or that are part of a picture that contains significant other visual content, have no contrast requirement.
• Logotypes: Text that is part of a logo or brand name has no contrast requirement.

Teacher App

Supports

Student App

Supports

InteDashboard ensures that all text, UI elements, and interactive components meet the required contrast ratios. Backgrounds and text colors are selected to provide sufficient visibility for users with low vision or color blindness, and all focus indicators and UI elements are accessible.

Text elements have a contrast ratio of at least 4.5:1, ensuring readability for users with visual impairments. Large and bold text meets the 3:1 ratio, and all buttons and interactive elements are clearly distinguishable with a contrast ratio of 3:1 or higher. The focus indicators on keyboard-navigable elements also meet the minimum contrast requirement. Additionally, non-text elements like buttons and input fields are clearly visible, providing users with a functional and accessible experience. The app avoids relying solely on color to convey meaning, ensuring that all critical information is accessible through multiple methods.

1.4.4 Resize Text
Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality.

Teacher App

Supports

Student App

Supports 

InteDashboard ensures that all text, including activity question stems, instructions, buttons, and form inputs, can be resized up to 200% without loss of content or functionality. The layout is responsive, allowing for proper scaling and preserving usability when text size is increased.

In InteDashboard, text is styled using relative units (e.g., em, rem) to allow for smooth resizing. When users zoom in up to 200%, all content remains visible and readable without breaking the layout or causing elements to overlap. Form fields, buttons, and interactive elements continue to function as expected, maintaining accessibility. The design adapts to ensure that users with visual impairments can enlarge text without losing access to the content or functionality of the app.Resize text functionality is provided for both learner and instructor users on the dashboard. Furthermore, instructor, teacher, staff and student users have the ability to resize the text in the app.

1.4.5 Images of Text
If the technologies being used can achieve the visual presentation, text is used to convey information rather than images of text except for the following:

Teacher App

Supports

Student App

Supports 

InteDashboard complies with WCAG 1.4.5 by ensuring that teachers are encouraged to upload text-based content (e.g., questions) instead of images of text. In cases where teachers do upload images containing text, the app allows them to provide descriptive alt text for those images. This ensures that the text content remains accessible to users with visual impairments who rely on screen readers or need to resize text.

In InteDashboard, teachers have the ability to upload images of question stems. While images of text are not ideal, the app allows teachers to provide alternative text (alt text) for each image they upload. This ensures that users can still access the question content, even if it is presented as an image. Additionally, the app encourages the use of real text for questions and provides guidance to teachers on how to make their content accessible. By ensuring that alt text is available for image-based content, the app remains compliant with WCAG 1.4.5 and ensures accessibility for all users.

1.4.10 Reflow (Added in 2.1)
Content can be presented without loss of information or functionality, and without requiring scrolling in two dimensions for:

• Vertical scrolling content at a width equivalent to 320 CSS pixels;
• Horizontal scrolling content at a height equivalent to 256 CSS pixels;
  Except for parts of the content which require two-dimensional layout for usage or meaning.

Teacher App

Supports

Student App

Partially Supports

Note: Minor non compliance as the edge-case scenario of a student making a > 300% zoom causes layout issues.

InteDashboard provides a fully responsive layout for both instructor and learner apps that ensures content reflows to fit smaller screens and works at up to 400% zoom without horizontal scrolling. The app avoids fixed-width elements and uses flexible layouts for questions, answers, and navigation elements. Exceptions are handled appropriately for 2D layouts like tables or media content uploaded by users.

InteDashboard implements responsive design principles using percentage-based widths and media queries to adapt content for small screens and zoom levels. All quiz questions, answers, and navigation components reflow correctly to ensure usability without requiring horizontal scrolling. Uploaded media files are scaled to fit the viewport, and exceptions for complex 2D layouts are minimal and managed to maintain accessibility. This ensures compliance with WCAG 1.4.10 and provides an inclusive experience for all users.

1.4.11 Non-text Contrast (Added in 2.1)
The visual presentation of the following have a contrast ratio of at least 3:1 against adjacent color(s):

• User Interface Components: Visual information required to identify user interface components and states, except for inactive components or where the appearance of the component is determined by the user agent and not modified by the author;
• Graphical Objects: Parts of graphics required to understand the content, except when a particular presentation of graphics is essential to the information being conveyed.

Teacher App

Partially Supports

Student App

Supports

All non-text UI components, graphical elements, and focus indicators meet the required contrast ratio of 3:1 against their backgrounds. Interactive elements, such as buttons, dropdowns, sliders, checkboxes, radio buttons and toggles, are visually distinct, even in hover and focus states. Graphical objects, like icons, are designed to maintain contrast for visibility.

InteDashboard uses a responsive design with sufficient contrast for all critical non-text elements. Buttons and interactive controls have clear boundaries and visual feedback that comply with contrast guidelines. Focus indicators for keyboard navigation are distinct and easily perceivable. Decorative elements, such as logos, are exempt from contrast requirements but are designed to avoid visual clutter. Instructor/Teacher/Staff-uploaded images are displayed within a UI that ensures appropriate contrast for accompanying elements like captions or frames.

1.4.12 Text Spacing (Added in 2.1)
In content implemented using markup languages that support the following text style properties, no loss of content or functionality occurs by setting all of the following and by changing no other style property:

• Line height (line spacing) to at least 1.5 times the font size;
• Spacing following paragraphs to at least 2 times the font size;
• Letter spacing (tracking) to at least 0.12 times the font size;
• Word spacing to at least 0.16 times the font size

Exception: Human languages and scripts that do not make use of one or more of these text style properties in written text can conform using only the properties that exist for that combination of language and script.

Teacher App

Supports

Student App

Supports 

InteDashboard that all text remains readable and functional when text spacing is modified according to the guideline’s requirements. No content is truncated or overlaps, and interactive elements dynamically adjust to accommodate the changes.

To achieve compliance, the following measures were implemented:

• Dynamic Text Containers: All text-based content, including quiz questions, instructions, and menus, uses flexible containers that expand based on content size, preventing clipping or overlap.
• Interactive Elements: Buttons, headers, and navigation menus resize dynamically to accommodate increased text spacing.
• Testing with Spacing Adjustments: Spacing adjustments were applied using browser tools and custom styles to ensure no loss of content or functionality: Line height was increased to 1.5 times the font size. Paragraph spacing was doubled. Letter and word spacing were adjusted to 0.12 and 0.16 times the font size, respectively.
• User-Generated Content: Teachers’ uploaded quiz questions are rendered in flexible containers that adapt to spacing changes, maintaining their readability and layout integrity.
• Responsive Design: The app uses a responsive design framework to ensure consistent behavior across devices and screen sizes when text spacing is modified.

1.4.13 Content on Hover or Focus (Added in 2.1)
Where receiving and then removing pointer hover or keyboard focus triggers additional content to become visible and then hidden, the following are true:

• Dismissible: A mechanism is available to dismiss the additional content without moving pointer hover or keyboard focus, unless the additional content communicates an input error or does not obscure or replace other content;
• Hoverable: If pointer hover can trigger the additional content, then the pointer can be moved over the additional content without the additional content disappearing;
• Persistent: The additional content remains visible until the hover or focus trigger is removed, the user dismisses it, or its information is no longer valid.
• Exception: The visual presentation of the additional content is controlled by the user agent and is not modified by the author.

Teacher App

Supports

Student App

Supports 

InteDashboard ensures that all hover-triggered or focus-triggered content is dismissable, hoverable, and persistent. Interactive elements such as tooltips, pop-ups, and drop-down menus have been designed to meet accessibility requirements.

To achieve compliance, the following steps were taken:

• Dismissable Content: Tooltips and pop-ups, such as error messages or quiz instructions, can be dismissed using the "Esc" key or by clicking outside the content.
• Hoverable Content: Hover-triggered tooltips (e.g., explanations for buttons or quiz options) remain visible when users move their pointer into the tooltip area, allowing interaction without premature disappearance.
• Persistent Content: Additional content remains visible until dismissed by the user or until it is no longer relevant (e.g., after navigating to a new screen).
• Keyboard Accessibility: All hover-triggered or focus-triggered content is accessible using keyboard navigation, ensuring compatibility with screen readers and other assistive devices.
• Avoiding Overlaps: Additional content is positioned to avoid obstructing important controls or text underneath, maintaining usability and readability.

2.4.5 Multiple Ways
More than one way is available to locate a Web page within a set of Web pages except where the Web Page is the result of, or a step in, a process.

Teacher App

Supports

Student App

Supports 

InteDashboard provides multiple ways for users to locate content, ensuring compliance with WCAG 2.4.5. Sequential processes like quiz-taking are appropriately restricted, with explanations provided.

• Search: Instructors and learners can use a search bar to locate courses, subjects, or reports efficiently.
• Navigation Menus: InteDashboard features consistent navigation menus with options such as "Activities," and "Grades" for learners and "Courses", "People", etc. for Instructors.
• Filters and Categories: Instructors can filter courses by subject, grade, or date created. Learners see categories like "Active Activities" or "Completed Activities."
• Process-Specific Navigation: During activity-taking, navigation is intentionally limited to maintain the integrity of the timed process. Users are informed of this restriction before starting the quiz.

2.4.6 Headings and Labels
Headings and labels describe topic or purpose.

Teacher App

Partially Supports

Student App

Supports

InteDashboard provides clear and descriptive headings and labels throughout, ensuring compliance with WCAG 2.4.6.

• Headings: Headings are used to structure content logically and describe sections clearly.
• Labels: Input fields and buttons are labeled descriptively, such as "Enter Activity Title" for text fields and "Start Activity" for action buttons.
• Semantic Markup: Proper heading tags (e.g., <h1>, <h2>) and form labels (<label>) are used, ensuring assistive technologies can interpret them correctly.

On the Instructor app, newly added features marked as "beta" do not have complete heading tags and labels which will be progressively fixed.

2.4.7 Focus Visible
Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible.

Teacher App

Partially Supports

Student App

Supports

InteDashboard provides a clear and visible focus indicator for all interactive elements.

• Default and Custom Focus Styles:
Default focus styles are retained for interactive elements. Custom focus styles, such as a 2px blue outline, are applied to improve visibility.
• Interactive Elements:
All buttons, links, and form inputs display a visible focus indicator, including "Start Activity," "Submit," and "Next Question."
• Keyboard Navigation:
Users can navigate the app using the Tab key, with focus moving logically and visibly between elements. Focus does not get trapped.

2.4.11 Focus Not Obscured (Minimum) (Added in 2.2)
When a user interface component receives keyboard focus, the component is not entirely hidden due to author-created content.

NOTE 1: Where content in a configurable interface can be repositioned by the user, then only the initial positions of user-movable content are considered for testing and conformance of this Success Criterion.

NOTE 2: Content opened by the user may obscure the component receiving focus. If the user can reveal the focused component without advancing the keyboard focus, the component with focus is not considered hidden due to author-created content.

Teacher App

Supports

Student App

Supports 

InteDashboard ensures that all interactive elements have a clearly visible and sufficiently large focus indicator, meeting WCAG 2.4.11.

• Focus Indicator Size: The focus indicator is a 2px solid outline or a contrasting border, providing a clear visual cue.
• Clarity: The focus indicator is sufficiently large to be easily noticed, ensuring it doesn’t blend into the background.
• No Obstruction: The focus indicator is never obscured by other elements, ensuring visibility at all times during keyboard navigation.

2.5.7 Dragging Movements (Added in 2.2)
All functionality that uses a dragging movement for operation can be achieved by a single pointer without dragging, unless dragging is essential or the functionality is determined by the user agent and not modified by the author.

NOTE: This requirement applies to web content that interprets pointer actions (i.e. this does not apply to actions that are required to operate the user agent or assistive technology).

Teacher App

Supports

Student App

Supports 

InteDashboard provies accessible alternatives for all drag-and-drop interactions.

• Non-drag Alternatives:
  The app does not rely solely on drag-and-drop for key interactions. For instance, elements like reordering questions can be performed using buttons or dropdown menus, ensuring accessibility for users who may have difficulty with drag gestures.
• Testing with Assistive Technologies:
  All drag-and-drop features have been tested using assistive technologies, including keyboard navigation and screen readers, confirming that non-drag alternatives function correctly.
• Consistent Feedback:
  Visual and audible feedback is provided consistently for both drag-and-drop and non-drag interactions, ensuring that users understand the outcome of their actions.

2.5.8 Target Size (Minimum) (Added in 2.2)
The size of the target for pointer inputs is at least 24 by 24 CSS pixels, except where:

• Spacing: Undersized targets (those less than 24 by 24 CSS pixels) are positioned so that if a 24 CSS pixel diameter circle is centered on the bounding box of each, the circles do not intersect another target or the circle for another undersized target;
• Equivalent: The function can be achieved through a different control on the same page that meets this criterion;
• Inline: The target is in a sentence or its size is otherwise constrained by the line-height of non-target text;
• User agent control: The size of the target is determined by the user agent and is not modified by the author;
• Essential: A particular presentation of the target is essential or is legally required for the information being conveyed

NOTE 1: Targets that allow for values to be selected spatially based on position within the target are considered one target for the purpose of the success criterion. Examples include sliders, color pickers displaying a gradient of colors, or editable areas where you position the cursor.

NOTE 2: For inline targets the line-height should be interpreted as perpendicular to the flow of text. For example, in a language displayed vertically, the line-height would be horizontal.

Teacher App

Supports

Student App

Supports 

InteDashboard ensures that all clickable elements, including buttons, links, and input fields, have a target size of at least 44x44 pixels and are adequately spaced for touch or click interactions.

• Minimum Target Size: All interactive elements, such as "Start Quiz", "Next Question", and form inputs, meet the minimum size requirement of 44x44 pixels to ensure ease of interaction for users with varying abilities.
• Adequate Spacing: There is sufficient spacing around interactive elements to prevent accidental interactions, ensuring that users can click or tap buttons with ease, particularly on touch devices.
• Touch Device Testing: The app has been tested on various touch devices to ensure that all interactive elements are large enough and easy to activate without requiring fine motor control.

3.2.2 Language of Parts
The human language of each passage or phrase in the content can be programmatically determined except for proper names, technical terms, words of indeterminate language, and words or phrases that have become part of the vernacular of the immediately surrounding text.

Teacher App

Supports

Student App

Supports 

InteDashboard complies with WCAG 3.1.2 by correctly identifying content in different languages with the appropriate lang attribute. When teachers input content in languages other than the primary language (English), the specific sections are marked with the correct language code.

• Primary Language of the App: The primary language of the app is set to English, with the lang="en" attribute in the <html> tag.
• Content in Other Languages: When teachers add questions or instructions in languages other than English, each piece of content is marked using the lang attribute to specify the language. For example, a Spanish question uses lang="es".
• Dynamic Content Handling: If a user switches languages or the content is dynamically loaded in a different language, the app ensures the lang attribute is updated accordingly for the new content.

3.2.3 Consistent Navigation
Navigational mechanisms that are repeated on multiple Web pages within a set of Web pages occur in the same relative order each time they are repeated, unless a change is initiated by the user.

Teacher App

Supports

Student App

Supports 

InteDashboard partially complies with WCAG 3.2.3. Navigation menus, repeated elements, and interactive features are presented consistently across all screens, ensuring a predictable and accessible user experience. However, context changes, such as screen redirection triggered by teacher actions or the timer expiring, occur programmatically and align with user expectations. Additional measures, such as providing detailed explanations or notifications of these behaviors, can further ensure alignment with the guideline.

• Consistent Navigation: InteDashboard’s primary navigation bar is always displayed at the left side of the screen for both students and teachers. Seondary navigation elements for the learner app, such as quiz controls ("Next Question," "Previous Question," "Submit Quiz"), appear in the same position across all quiz pages.
• Predictable Layout: Buttons, timers, and question numbers are consistently located, ensuring users can navigate through quizzes without confusion. Even when users navigate to secondary screens like "Settings" or "Help," the navigation bar remains consistent.
• Dynamic Content Management: InteDashboard avoids dynamically rearranging navigation menus or elements unless initiated by user preferences. Any newly introduced dynamic content integrates logically without altering the position of existing elements. By ensuring consistent navigation, the app avoids unnecessary confusion and supports users relying on assistive technologies or those with cognitive impairments.
• Teacher-Controlled Redirection: Instructors have the ability to force-end activities or redirect students to specific question pages during discussions. These actions are intentional and provide instructional value, ensuring students follow the teacher's flow during collaborative learning.
• Planned Updates: Future updates will improve compliance by:
• Providing advance Notice and Clarity: While these actions are predictable within the app's design, informing students beforehand (e.g., "Your screen may automatically change based on teacher actions or timer settings") helps maintain consistency with the guideline's intent and supports a smooth user experience. 

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

Teacher App

Supports

Student App

Supports 

InteDashboard fully complies with WCAG 3.2.4 by maintaining consistent identification of components with the same functionality across all teacher and student interfaces.Consistent Button Labels and Icons:

• Buttons like "Save Answer," "Next Question," and "Submit Quiz" retain identical labels and icons across all screens in both the learner and instructor app. Similarly, the instructor app uses consistent labels for features such as "End Activity," "View Results," "Start Timer," etc.
• Uniform Placement and Design:
  Navigation menus, action buttons, and interactive elements are positioned consistently across all app screens, ensuring a predictable and intuitive experience.
  Standard styling is applied to all elements with the same purpose, such as using a green button for "Submit" actions and a gray button for "Cancel" actions.
• Tooltips and ARIA Labels:
  Tooltips and ARIA labels provide consistent descriptive text, such as “Save your answer for this question” for the "Save Answer" button, across all screens.
• Regular Audits:
  Periodic design and functionality reviews are conducted to ensure uniformity in identification, minimizing the risk of user confusion.

3.3.3 Error Suggestion
If an input error is automatically detected and suggestions for correction are known, then the suggestions are provided to the user, unless it would jeopardize the security or purpose of the content.

Teacher App

Partially Supports

Student App

Supports 

InteDashboard is mostly compliant with WCAG 3.3.3, offering clear and helpful error suggestions for many input fields. While the learner app is fully equipped with error suggestions, there are some areas in the instructor app that will be improved in a future update to ensure consistent guidance across all fields.

• Error Detection and Suggestions: In the learner app, error suggestions are well integrated. For example, if a question is left unanswered, the system prompts with “Please answer this question before proceeding.” For the instructor app, error suggestions are currently available for some fields, such as email addresses, passwords etc. However, there are plans to expand this feature, including guidance for errors related to activity file uploads or configuration issues, to make the app even more user-friendly.
• Specific Guidance for Complex Fields: In the learner app, guidance is provided when errors are detected, ensuring that users know how to fix the issue. The instructor app currently offers guidance in most areas but lacks specific error suggestions in others, such as when invalid question stem formats are entered. This is a planned improvement that will be addressed in an upcoming update to ensure consistency across the platform.
• Automated Suggestions: Automated error suggestions are already in place for fields like email addresses in both the instructor and learner apps. However, for other more complex fields like media uploads, this feature is still under development. A future update will bring automated suggestions for file format and size errors to ensure a seamless experience for all users.
• Preventing Common Errors: The learner app is proactive in preventing common errors, such as providing instructions for unanswered questions. The teacher app, while it offers some preventive instructions, will be enhanced in a future update with additional guidance, such as file format suggestions and tips for filling out quiz fields correctly, ensuring an even smoother workflow for teachers.

3.3.4 Error Prevention (Legal, Financial, Data)
For Web pages that cause legal commitments or financial transactions for the user to occur, that modify or delete user-controllable data in data storage systems, or that submit user test responses, at least one of the following is true:

• Reversible: Submissions are reversible.
• Checked: Data entered by the user is checked for input errors and the user is provided an opportunity to correct them.
• Confirmed: A mechanism is available for reviewing, confirming, and correcting information before finalizing the submission.

Teacher App

Supports

Student App

Supports 

InteDashboard fully complies with WCAG 3.3.4 by providing mechanisms that prevent errors from leading to unintended consequences, particularly in critical actions like submitting activities or editing sensitive data. Users are given clear opportunities to review and confirm their actions.

• Review Before Finalizing: Before teachers publish activities, they are given the option to review their settings, question formats, and media uploads to ensure everything is correct before commits. This allows instructors to confirm their selections and make corrections if necessary.
• Confirmation Dialogs for Critical Actions: When instructors finalize a quiz for distribution, a confirmation dialog is displayed, asking them to confirm, “Are you sure you want to publish this activity?” This ensures that accidental submissions are prevented.
• Undo or Edit Options: After publishing an activity, instructors have the option to reset the activity. This enables users to correct mistakes before the quiz is sent out to students. Moreover, we have provided a feature that allows instructors to edit copywriting of queastion stems and change answer keys.
• Clear Warnings for Potential Errors: If an instructor attempts to delete an activity or question set, a warning message is shown: “Deleting this quiz is permanent and cannot be undone. Are you sure?” This helps avoid irreversible actions by mistake.
  

3.3.8 Accessible Authentication (Minimum) (Added in 2.2)
A cognitive function test (such as remembering a password or solving a puzzle) is not required for any step in an authentication process unless that step provides at least one of the following:

• Alternative: Another authentication method that does not rely on a cognitive function test.
• Mechanism: A mechanism is available to assist the user in completing the cognitive function test.
• Object Recognition: The cognitive function test is to recognize objects.
• Personal Content: The cognitive function test is to identify non-text content the user provided to the Web site.

NOTE 1: What is perceived as the user interface component or sub-component (to determine enclosure or size) depends on its visual presentation. The visual presentation includes the component's visible content, border, and component-specific background. It does not include shadow and glow effects outside the component's content, background, or border.

NOTE 2: Examples of mechanisms that satisfy this criterion include:

1. support for password entry by password managers to reduce memory need, and
2. copy and paste to reduce the cognitive burden of re-typing.

Teacher App

Supports

Student App

Supports 

InteDashboard complies with WCAG 3.3.7 by offering accessible authentication processes, including support for LTI integration, alternative authentication methods, and clear instructions for login. Users can authenticate without relying solely on memory, with fallback options available if LTI authentication fails.

• Alternative Authentication Methods: In addition to native authentication via email and password, the app supports LTI-based Single Sign-On (SSO) for users accessing external learning tools. This allows teachers and students to authenticate once and seamlessly access both the main app and integrated LTI tools.
• Clear Instructions: Detailed instructions are provided for users who need to log in via LTI, with steps to troubleshoot and reauthenticate if the SSO process encounters issues.
• Non-reliance on Cognitive Abilities Alone: Users are not required to memorize multiple passwords for different tools. By supporting SSO, the app reduces the cognitive load and prevents users from having to recall credentials for multiple systems.
• Error Detection and Suggestions: If LTI-based authentication fails, users are presented with clear error messages and given the option to authenticate using traditional methods (e.g., resetting their password via email).
• Timeouts and Session Expiry: If an LTI session expires, users are notified, and they can reauthenticate easily through either LTI or traditional login methods without losing their data or progress.

4.1.3 Status Messages (Added in 2.1)
In content implemented using markup languages, status messages can be programmatically determined through role or properties such that they can be presented to the user by assistive technologies without receiving focus.

Teacher App

Supports

Student App

Supports 

InteDashboard provides accessible status messages for key actions, such as quiz submissions, timer warnings, and automatic screen updates. These messages are conveyed to assistive technologies without requiring user action.

To comply with WCAG 4.1.3, InteDashboard uses ARIA live regions (aria-live) and alert roles (role="alert") to ensure that students using assistive technologies receive real-time updates when important status changes occur. For example, when a quiz is submitted, an announcement is made without shifting focus. Similarly, when a teacher force-ends a quiz, a message informs students before they are redirected. These measures ensure that all users, including those relying on screen readers, receive crucial status updates effectively.

504 Authoring Tools

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

See WCAG 2.2 section

See information in WCAG 2.2 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.2 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.2 section at the top of this document

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

Student App

Supports

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

Student App

Supports

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

Student App

Supports

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

Student App

Supports

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.2 section at the top of this document

11.8.3 Preservation of accessibility information in transformations

-

See information in WCAG 2.2 section at the top of this document

11.8.4 Repair assistance

-

See information in WCAG 2.2 section at the top of this document

11.8.5 Templates

-

See information in WCAG 2.2 section at the top of this document

12.1 Product documentation

12.1.1 Accessibility and compatibility features

Teacher App

Supports

Student App

Supports

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.2 section at the top of this document

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

Supports

Student App

Supports

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.2 section at the top of this document