Accessibility
Murelio treats accessibility as part of product quality so core tools can be used across disabilities, input methods, and screen sizes. WCAG 2.2 Level AA is a design target, but Murelio does not claim an independently certified, site-wide conformance status.
1. Accessibility goal
Core navigation and controls should be operable by keyboard where practical, inputs should have meaningful names and guidance, and important states should not be communicated by color alone.
Accessibility is treated as a baseline quality consideration for new tools and screens rather than an optional add-on.
2. Keyboard access
Links, buttons, inputs, and selection controls should receive visible keyboard focus. Modals and search interfaces should provide predictable focus and closing behavior.
Where a feature might otherwise rely on dragging, alternative controls such as buttons, explicit values, or ordering controls are preferred where practical.
3. Screen readers and semantic structure
Headings, labels, button names, status regions, and errors should use semantic structure and accessibility attributes rather than relying only on visual placement.
When important tool results change dynamically, the interface considers how assistive-technology users can become aware of the updated result.
4. Color and contrast
Text and controls are intended to remain distinguishable from their backgrounds, and error, success, or selection states should not rely on a single color alone.
Light, dark, and system themes should preserve the same information structure without causing important text to disappear or become unreadable.
5. Zoom and responsive layouts
Layouts are designed for phone, tablet, desktop, narrower viewports, and browser zoom with the aim of reducing horizontal overflow and overlapping content.
Touch targets should not become unnecessarily small, and information required to use a tool should not depend solely on mouse hover.
6. Motion and animation
Reduced-motion preferences are considered so non-essential animation can be minimized. Where an animation represents a process, the final state should remain understandable without requiring the user to follow every frame.
Rapid or excessive motion should not interfere with essential information.
7. Errors and input assistance
Where possible, validation explains what is wrong, what range or format is expected, and how the user can correct it instead of relying only on a colored border.
Controls such as sliders may provide direct numeric input and increment or decrement actions when precision would otherwise be difficult.
8. Known limitations
Some canvas visualizations, game-like interactions, file previews, and browser-native interfaces can be less accessible than ordinary forms. Alternative text, explicit result values, and additional controls are areas of ongoing improvement.
Browser-owned file pickers, download interfaces, and permission prompts are not fully controlled by Murelio and depend on operating-system and browser accessibility.
9. Assessment approach
Accessibility is not evaluated only through automated checks. Keyboard navigation, focus behavior, responsive layouts, and practical use in major browsers are also reviewed.
Murelio targets WCAG 2.2 Level AA but does not state that every page currently meets every criterion without exception.
10. Accessibility feedback
Report public accessibility problems through GitHub Support. If the report must contain private information or sensitive details about an assistive-technology setup, send it to [email protected].
Including the page, browser, device, assistive technology, expected behavior, and actual behavior helps investigation.