Accessibility and Language Clinic
Tabs
Why accessibility is indispensable in ILIAS
Accessibility means equal participation. It enables independent use and non-discriminatory access, regardless of individual circumstances or assistive technologies. For public institutions, it is also a legal requirement in the EU. Among other things, EU directives, EN 301 549, and national regulations such as BITV 2.0 are decisive. For ILIAS, as a widely used open-source learning management system, this results in a special responsibility. Accessibility is not an optional feature. It is a quality feature and an expression of professional software development.
As the accessibility and language experts, we are committed to establishing accessibility and clear, understandable language as integral components of ILIAS development—in design, code, and editorial layout.
Digital participation does not happen by chance. It is the result of conscious decisions.
How to contact us
A11y-Clinic
In the A11y Clinic, you can get advice on accessibility in the context of ILIAS components and get practical advice on how to improve accessibility. Giercke-Ungermann, Annett [Annett_Giercke] is offering support with all accessibility-related issues.
The A11y Clinic takes place every Wednesday after the Jour Fixe from 10h00 to 11h00. Please announce the topic you would like to discuss by e-mail: a11y-clinic@ilias.de
01.09.2025
We have decided to stop the bi-weekly UI clinic consultation hours for UI/UX and accessibility topics due to lack of demand.
It seems that this format no longer reflects the spirit of the times and does not offer the help that was still desired a few years ago.
If you have any questions about UI, accessibility, and/or languages, please feel free to contact us in writing. We will be happy to assist you.
UI Coordinators and the Accessibility & Language Expert Group can be reached through their own email address:
ux@lists.ilias.de
Norms, standards and legal foundations
Accessibility in ILIAS is based on binding international and national standards. The EU Directive 2016/2102, EN 301 549 with the underlying WCAG, are particularly relevant. These standards define specific requirements for the perceptibility, operability, comprehensibility, and robustness of digital systems. For us, this means that accessibility is not an add-on, but a normative quality standard – in the core, in plugins, and in editorial content.
Practical implementation
This section specifies the requirements for digital accessibility at the practical implementation level. Based on the relevant standards and guidelines (iEN 301 549 with included WCAG), structural, content-related, and technical measures are described that support the accessible design of learning and information offerings in ILIAS.The focus is on the systematic application of accessible design principles (perceptibility, operability, comprehensibility, and robustness), the correct semantic structuring of content, the accessible preparation of multimedia materials, and ensuring consistent navigation and interaction logic. The aim is to anchor accessibility not as a downstream correction, but as an integral part of didactic and technical development processes.
Here you will find the most important requirements - in a nutshell.
For UI components (system level)
Core components must:
- Be fully keyboard-operable
- Have a clean semantic HTML structure
- Use correctly implemented ARIA patterns
- Guarantee visible focus
- Be screen reader-compatible
Particularly critical:
- Modal dialogs
- Dropdowns
- Main navigation
- Table components
- Form builder
- Pagination
- Drag & drop
Framework & templates
- No div soup
- No JavaScript without fallback
- Implement focus management systematically
- Define landmark structure
- Integrate skip links system-wide
The following should apply to core merges:
- Keyboard test passed
- Screen reader test performed
- Axe without critical errors
- Contrast checked
- Zoom test (200%/400%)
For Plugin developers
- Plugins have integration responsibilities. They must not:
- Introduce new barriers
- Undermine existing standards
Basic principle
- Use existing ILIAS UI components.
- Do not build your own complex widgets if core solutions are available.Homemade = high A11y risk.
Forms in the plugin
- Each field needs a <label>.
- Error messages are: textually unambiguous and linked to the field
- Required fields not just mark with color
- Groupings with <fieldset> / <legend>
Interactive elements
- No click on <div>
- No pure mouse interaction
- Take keyboard events into account
- No automatic loss of focus
- Escape options for dialogs
Dynamic content - When content is reloaded via JS:
- ARIA Live only when useful
- Announce status changes
- No “invisible” UI for screen readers
Tables & data
- Use <th> correctly
- Set scope attributes
- No layout tables
- Make sorting functions accessible
Content in plugins
- Enable alt text
- Generate structured headings
- Consider accessible PDFs
- Subtitle option for video integration
Empty Title
Previous Work & Helpful Information
The UI Clinic was a place where you could get advice about building nice user interfaces, offering great user experience and accessibility and using or extending the ILIAS UI framework.
The on-demand consulation-hours have been offered by Kristina Auerswald, Kendra Grotz, Yvonne Seiler, Nils Haagen, Timon Amstutz and Richard Klees, as a service of the coordinators of the ILIAS UI Framework together with UI/UX/Ally-experts of the community and regular contributors to the UI Framework.
Sitzungen
Links - Material
