1) Our commitment
We strive to make this application accessible to as many people as possible. We aim for WCAG 2.1 AA compliance level when reasonably possible. However, we acknowledge that the application is not guaranteed to be 100% accessible today.
2) What is already implemented
- Semantic HTML structure (titles, headings, lists).
- Keyboard navigation for main elements (menus, forms).
- Color contrasts tested for most components.
- Alt attributes on informative images when provided.
- Minimal ARIA semantics where needed (roles and labels).
- Visible focus and basic focus management after major interactions.
3) Known limitations
Despite our efforts, we have identified (or estimate possible) the following limitations:
- Complex visual components (graphics, canvas, animations) that may interfere with some screen readers or cause distractions.
- Dynamic content loaded after interaction (modals, asynchronous content) that may require ARIA announcements and focus management improvements.
- Complex forms where some labels or descriptions may be missing or insufficient.
- Multimedia (video/audio) does not systematically have subtitles or complete transcripts.
- Possible contrast issues on custom themes or with user content.
If you encounter a specific barrier, please report it — see the Report a Problem section below.
4) How we test
Our tests include:
- Automatic audits (Lighthouse, axe-core) on main pages.
- Manual keyboard tests and with popular screen readers (NVDA, VoiceOver) on critical flows.
- Contrast checks and UI component reviews.
We keep test reports and prioritize fixes based on user impact and technical feasibility.
5) Improvement roadmap
- Fix critical issues identified by axe-core and Lighthouse on creation and registration pages.
- Add ARIA announcements and improve focus management for modals and dynamic content.
- Transcribe/caption important video content.
- Improve form accessibility (explicit labels, accessible errors).
- Conduct user testing with people with disabilities for essential flows.
6) Mitigation measures and tips
While waiting for fixes, here are some tips to work around certain obstacles:
- Use tab navigation and browser search to quickly reach sections.
- If an image or media lacks description, activate the browser's reader mode or request transcription via contact.
- If a form doesn't focus on an error, go directly to required fields and use Ctrl/Cmd+F to find labels.
7) Report a problem
If you encounter an accessibility barrier, please provide us with the following information:
- URL (or specific step) where the problem occurs.
- Description of the problem and its impact.
- Operating system, browser and screen reader (if known).
- Screenshot or recording if possible.
To report: Contact page.
8) Response commitment
We acknowledge receipt of reports within 5 business days and provide a response or action plan within 30 business days when possible. If your report requires urgent action (e.g., complete inability to use an essential flow), please indicate this clearly for prioritization.
9) Technical accessibility — concrete points for developers
- Check DOM order to respect visual order.
- Add explicit labels for all form controls.
- Manage focus: set focus on open modals and restore it on close.
- Use role, aria-label and aria-describedby only when necessary and correctly.
- Provide text alternatives for all non-text content.
- Avoid excessive animations or provide a way to reduce them (prefers-reduced-motion).
This document is provided for informational purposes only and does not replace legal advice. It is only for the ESGI course project, all of this remains as an example and fictional.
