1. Scope of this statement
This statement covers three distinct layers of NursEscape:
Public website
Including pages such as:
- Home,
- About,
- How It Works,
- Educational Approach,
- For Institutions,
- Research & Innovation,
- Healthcare Innovation Laboratory,
- Contact,
- Privacy,
- Cookies,
- Terms,
- Accessibility,
- Sitemap.
Authenticated NursEscape platform
Including functionality such as:
- sign in,
- learner assignments,
- course/group context,
- Launch / Resume,
- results,
- certificates,
- instructor management,
- Results Dashboard.
Independent Room Packages
Digital escape rooms are independent frontend web applications that run inside NursEscape.
The accessibility of an individual Room Package also depends on the way that room has been designed and developed.
An accessible platform shell therefore does not, by itself, guarantee that every room experience is accessible.
2. Target standard
NursEscape's accessibility target is:
Web Content Accessibility Guidelines (WCAG) 2.2 — Level AA
WCAG includes principles and success criteria relating to areas such as:
- keyboard access,
- visible focus,
- semantic structure,
- labels and instructions,
- error identification,
- text alternatives,
- captions,
- contrast,
- responsive content,
- motion,
- status messages,
- consistent navigation,
- target size,
- focus not obscured.
3. Accessibility measures already incorporated
Based on the current production implementation, NursEscape includes design and engineering practices such as:
Semantic structure
Logical HTML structure, headings and landmarks are used where appropriate.
Skip navigation
A skip-navigation mechanism enables keyboard users to bypass repeated navigation and move to the main content.
Keyboard-accessible navigation
Core navigation is designed to be operable using a keyboard.
Visible interaction state
Interactive controls should retain a visible focus state.
Navigation state
Accessibility attributes such as:
aria-expanded,aria-current
are used where appropriate for navigation and expandable controls.
Form labels
Form controls use visible labels rather than relying exclusively on placeholder text.
Field-specific errors
Validation errors are associated with the relevant field.
Invalid-field state
aria-invalid is used where a control is in an invalid state.
Descriptive relationships
aria-describedby is used where needed for helper text and validation messages.
Focus after validation
Following form validation, the interface can direct focus to the first invalid field or appropriate error context.
Reduced motion
Design takes user reduced-motion preferences into account.
Responsive layouts
Public and platform layouts are designed to adapt across viewport sizes.
Contrast considerations
The visual system and UI states are designed with contrast in mind.
4. Content and structure
Accessibility also depends on content design.
NursEscape public content should follow principles such as:
- one clear H1 per page,
- logical H2/H3 hierarchy,
- descriptive link text,
- clear labels,
- avoiding generic “click here” links when descriptive anchors are possible,
- real text rather than important text embedded only in images,
- clear instructions,
- concise paragraphs,
- correct document language,
- meaningful page titles.
5. Images and graphics
Informative images should have appropriate text alternatives.
Purely decorative images should use:
alt=""
For screenshots or diagrams that communicate substantive information:
- alt text should describe the purpose,
- the complete information should also exist in surrounding HTML text,
- the diagram must not be the sole source of information.
6. Colour and visual communication
Colour should not be the only means of communicating information.
Examples:
- error states need text,
- success/error status needs explicit wording,
- charts need labels/legends beyond colour,
- required fields need text identification,
- active/inactive state should differ in more than colour alone.
7. Keyboard interaction
Core functionality should be operable without a mouse.
This includes:
- navigation,
- buttons,
- links,
- forms,
- dropdowns,
- modal dialogs,
- accordions,
- language selector,
- platform controls.
8. Focus management
Keyboard focus should remain visible and move in a logical order.
Particular attention is required for:
- modal dialogs,
- menus,
- validation errors,
- login flows,
- result dialogs,
- certificate interfaces,
- room launch/resume transitions.
9. Forms and validation
Forms should provide:
- visible labels,
- clear required-field indication,
- accessible helper text,
- field-specific errors,
- textual error descriptions,
- appropriate focus management,
- preservation of user-entered values after validation errors where practical.
Errors should not be identified by colour alone.
10. Motion and animation
Animation can contribute to an experience but should not create unnecessary barriers for users with motion sensitivity.
The platform takes the preference:
prefers-reduced-motion
into account.
11. Audio and video
Where the public site or a Room Package includes audio/video content, accessibility may require:
- captions,
- transcripts,
- audio description where appropriate,
- keyboard-accessible media controls,
- controls for autoplay,
- visual alternatives to audio-only information.
12. Timed interactions
Timed educational interactions can create accessibility barriers.
The current platform should not be presented as having a universal completed server-authoritative timer engine.
13. Drag-and-drop and complex interactions
Room Packages may technically contain interactions such as drag-and-drop, hotspots or complex puzzle mechanics.
When used, the design should consider whether a keyboard-accessible or equivalent method is available.
14. Independent Room Packages
NursEscape does not include an internal visual escape-room builder.
Each room is an independent frontend application and may use different technologies and interaction patterns.
Accessibility therefore needs to be assessed at the individual-room level.
Room author responsibilities
An accessible Room Package should consider at least:
- semantic HTML,
- keyboard access,
- visible focus,
- labels,
- image alternatives,
- contrast,
- non-colour cues,
- captions/transcripts,
- reduced motion,
- pointer alternatives,
- accessible error/feedback messages,
- responsive layout,
- screen-reader compatibility where applicable.
15. Accessibility and educational design
A technically accessible interface can still be educationally difficult to use.
Accessibility review should therefore also consider:
- clarity of instructions,
- cognitive load,
- readability,
- predictable navigation,
- consistent terminology,
- time pressure,
- unnecessary complexity,
- feedback clarity.
16. Certificates
Certificates of completion should be accessible both in the interface and, where practical, as downloadable documents.
17. Current accessibility status
The safe public position today is:
NursEscape is being designed with WCAG 2.2 Level AA as its accessibility target.
The following have not yet been completed:
- a full independent accessibility audit,
- a documented WCAG 2.2 AA conformance review of the entire public site,
- a documented WCAG 2.2 AA conformance review of all authenticated platform flows,
- a universal accessibility audit of every Room Package.
The following wording should therefore not be used today:
- “fully WCAG 2.2 AA compliant”,
- “100% accessible”,
- “fully accessible to all users”.
18. Accessibility testing
Automated testing
Useful for identifying selected issues such as:
- missing labels,
- invalid ARIA,
- contrast problems,
- structural errors.
Manual keyboard testing
For:
- focus order,
- keyboard traps,
- dropdowns,
- dialogs,
- forms,
- room interactions.
Screen-reader testing
For:
- names/roles/values,
- landmarks,
- headings,
- forms,
- announcements,
- dynamic updates.
Zoom and reflow testing
For:
- browser zoom,
- text resizing,
- small viewport reflow.
User testing
Where practical, include users who use assistive technologies.
19. Feedback and reporting accessibility barriers
If you encounter an accessibility barrier in NursEscape, we want to know about it.
You can contact:
Email: hil@uth.gr
Where possible, please include:
- the page or feature,
- what you were trying to do,
- the problem you encountered,
- browser/device,
- assistive technology, only if you choose to share it.
You do not need to disclose information about a disability or medical condition.
20. Alternative access
If information or functionality is not accessible to you, you may contact hil@uth.gr and explain what you need.
Where practical and institutionally appropriate, an alternative way of accessing the relevant information or completing the relevant process will be considered.
21. Institutional deployments
In institutional use, accessibility responsibility concerns both:
- the NursEscape platform,
- the specific educational content / Room Package.
22. Updating this statement
This Accessibility Statement should be updated when:
- a new accessibility audit is completed,
- a significant issue is fixed,
- a new complex component is added,
- navigation changes,
- a new class of Room Package interaction is introduced,
- the accessibility-feedback contact changes,
- relevant standards or institutional requirements change.
23. Related pages
- Contact
- Privacy Policy
- Cookie Policy
- Terms of Use
- How It Works