From 13d46eeda27069bcddfa2c408f8faaaa8fbb6fd4 Mon Sep 17 00:00:00 2001
From: Annett7811 <159028979+Annett7811@users.noreply.github.com>
Date: Wed, 19 Aug 2026 08:15:21 +0200
Subject: [PATCH] Update: Revise accessibility process documentation
Updated terminology in the accessibility process documentation to reflect the new expert group name and responsibilities.
---
docs/development/accessibility-process.md | 156 +++++++++++-----------
1 file changed, 78 insertions(+), 78 deletions(-)
diff --git a/docs/development/accessibility-process.md b/docs/development/accessibility-process.md
index dca11bab2854..bbf75e07d017 100755
--- a/docs/development/accessibility-process.md
+++ b/docs/development/accessibility-process.md
@@ -22,7 +22,7 @@ concrete goals are:
* Targets for incremental improvements are identified regularly, be it concrete
areas of the system itself or processes, tools and approaches used to work towards
a better accessibility of ILIAS.
-* An [expert group](./expert-groups.md) for UI, UX and accessibility is appointed.
+* An [expert group](./expert-groups.md) for accessibility and language is appointed.
The group is a central point of contact for all questions related to ILIAS' user
interface and accessibility.
* External accessibility experts are consulted regularly to improve the general
@@ -45,81 +45,81 @@ To achieve these goals, various people need to participate in different roles du
the release cycle. This section should help to clarify the expectations towards these
participants. Roles central to the process are listed first.
-* [UI/UX/A11y Expert Group](../development/expert-groups.md)
+* [Accessibility and Language Expert Group:](../development/expert-groups.md)
* supports maintainers and developers on general and specific questions regarding
- feature requests, issue tickets and implementations
- * works on processes and strategies to improve processes
- * sends members to the SIG Accessibility and takes part in the discussions there
- * works with UI-Coordinators to improve components and processes
- * analyses accessibility reports
- * reviews and improves test suites
- * provides feedback on feature requests before Jour Fixe
- * sends member to take part in Jour Fixe to answers questions on issues and features
- * carries out an annual review of this process
+ feature requests, issue tickets and implementations;
+ * works on processes and strategies to improve processes;
+ * sends members to the SIG Accessibility and takes part in the discussions there;
+ * works with UI-Coordinators to improve components and processes;
+ * analyses accessibility reports;
+ * reviews and improves test suites;
+ * provides feedback on feature requests before Jour Fixe;
+ * sends member to take part in Jour Fixe to answers questions on issues and features or attends the meeting personally;
+ * carries out an annual review of this process;
* provides a point of contact for inquiries regarding user interface, user experience
- and accessibility
- * is responsible for this document
+ and accessibility;
+ * is responsible for this document.
-* [Maintainers and Developers](../development/maintenance.md)
- * develop new components and features in accordance with the accessibility guidelines
+* [Maintainers and Developers:](../development/maintenance.md)
+ * develop new components and features in accordance with the accessibility guidelines;
* apply the accessibility checklist to their own projects and review their own code
- with focus on accessibility
- * acquire a sound understanding of accessibility
+ with focus on accessibility;
+ * acquire a sound understanding of accessibility;
* get in contact with the expert group to improve their understanding of accessibility
- issues or our guidelines
+ issues or our guidelines.
-* [UI-Coordinators](../../components/ILIAS/UI/docs/COMMUNITY.md)
- * triage objectively testable accessibility bugs for UI components
- * checks if formal requirements are met and code is at the correct location
- * acquire a sound understanding of accessibility
- * get in contact with the expert group to improve their understanding of accessibility
+* [UI-Coordinators:](../../components/ILIAS/UI/docs/COMMUNITY.md)
+ * triage objectively testable accessibility bugs for UI components;
+ * checks if formal requirements are met and code is at the correct location;
+ * acquire a sound understanding of accessibility;
+ * get in contact with the expert group to improve their understanding of accessibility.
-* [Community Tester for Accessibility](https://docu.ilias.de/goto_docu_pg_9809_42.html)
- * carries out test cases of the accessibility test suite in the beta phase
+* [Community Tester for Accessibility:](https://docu.ilias.de/goto_docu_pg_9809_42.html)
+ * carries out test cases of the accessibility test suite in the beta phase;
* uses a simple diagnostic browser extensions like WAVE or Lighthouse to
- automate a part of testing
+ automate a part of testing;
* provides feedback on quality and coverage of the accessibility test suite to the
- Test Case Author for Accessibility
+ Test Case Author for Accessibility.
-* Test Case Author for Accessibility
+* Test Case Author for Accessibility:
* prepares, organises and writes test cases of the Accessibility Test Suite
according to rules in KS-entries, FW-entries and objectively testable
- requirements in accessibility guidelines
+ requirements in accessibility guidelines;
* supports Community Tester for Accessibility, improves cases upon feedback
- from community tester or developer
+ from community tester or developer;
* analyses Accessibility Assessment Reports. Reviews Test Suite in the light
- of said report and makes changes accordingly
- * has sound understanding of accessibility
- * is recruited and appointed by the UI/UX/A11y expert group
- * works in close coordination with or is member of the UI/UX/A11y expert group
+ of said report and makes changes accordingly;
+ * has sound understanding of accessibility;
+ * is recruited and appointed by the Accessibility and Language Expert Group;
+ * works in close coordination with or is member of the Accessibility and Language Expert Group.
-* [Chair SIG Accessibility](https://docu.ilias.de/goto_docu_grp_6949.html)
+* [Chair SIG Accessibility:](https://docu.ilias.de/goto_docu_grp_6949.html)
* Role requirements are described in [Rules of Procedure](https://docu.ilias.de/goto_docu_cat_3773.html)
for Special Interest Groups.
* advocates accessibility to community i.e. ensures reports are prepared and
- presented on DevConfs
- * organizes or initiates or delegates the fundraising
+ presented on DevConfs;
+ * organizes or initiates or delegates the fundraising.
-* Accessibility Contractor
+* Accessibility Contractor:
* is contracted to perform audits and run accessibility trainings for developers
- and community members
- * is contracted to advise and consults on major UI Developments
+ and community members;
+ * is contracted to advise and consults on major UI Developments;
* Accessibility contractors should be tendered and selected from BITV-Test-
Prüfverband or similar.
-* Managing Director of ILIAS society
- * contracts external Beta Accessibility Assessment with dedicated agency
+* Managing Director of ILIAS society:
+ * contracts external Beta Accessibility Assessment with dedicated agency.
-* Product Manager
- * ensures accessibility is aptly considered in feature requests in Jour Fixe
+* Product Manager:
+ * ensures accessibility is aptly considered in feature requests in Jour Fixe.
-* [Technical Board](https://docu.ilias.de/goto_docu_grp_5089.html)
- * appoints UI/UX/A11y expert group, makes sure that the group works as intended
- and takes responsibility, if the group does not function as intended
- * is responsible for the general form and direction of the accessibility process
+* [Technical Board:](https://docu.ilias.de/goto_docu_grp_5089.html)
+ * appoints Accessibility and Language Expert Group, makes sure that the group works as intended
+ and takes responsibility, if the group does not function as intended;
+ * is responsible for the general form and direction of the accessibility process.
-* Community Test Manager
- * coordinates accessibility testing
+* Community Test Manager:
+ * coordinates accessibility testing.
@@ -128,31 +128,31 @@ participants. Roles central to the process are listed first.
To support the work in the various stages of the release cycle the community
uses different tools. This section clarifies the purpose and usage of these tools.
-* [Accessibility Guidelines](./accessibility.md)
+* [Accessibility Guidelines:](./accessibility.md)
* The Accessibility Guidelines inform the development of new features, KS-entries
etc. and determine potential improvements of existing features, KS-entries etc.
- * The Accessibility Guidelines are based on the WCAG and put these guidelines
+ * The Accessibility Guidelines are based on the EN 301 549 and put these guidelines
in the context of ILIAS. The guidelines are supplemented with:
* specific rules in KS entries which interpret guidelines for UI-elements
* the Accessibility Checklist, that interprets guidelines to make them
objectively testable wherever possible
* We accept that there is ambivalence in the rules that are not objectively
testable. We strive to shrink this ambivalence.
- * Accessibility guidelines are kept in synch with WCAG developments.
+ * Accessibility guidelines are kept in synch with EN 301 549 developments.
* The Accessibility Guidelines refer to resources on specific accessibility
issues for all consumers to look up and self-educate.
-* [Accessibility Checklist](./accessibility.md#Checklist)
+* [Accessibility Checklist:](./accessibility.md#Checklist)
* The Accessibility Checklist is documented as md-file along with the
Accessibility Guidelines.
* Maintainers and Developers use the Accessibility Checklist to assess
accessibility of their ongoing implementation projects.
-* [Feature Wiki](https://docu.ilias.de/goto_docu_wiki_wpage_1_1357.html)
+* [Feature Wiki:](https://docu.ilias.de/goto_docu_wiki_wpage_1_1357.html)
* The Maintainer has to fill in the section "Accessibility Implications" and
complete it before the article can be finally decided on the Jour Fixe.
- He may contact the UI/UX/A11y Expert Group for support.
- * The UI/UX/A11y Expert Group reviews Feature Wiki entries at their own discretion
+ He may contact the Accessibility and Language Expert Group for support.
+ * The Accessibility and Language Expert Group reviews Feature Wiki entries at their own discretion
and provides feedback about potential issues as early as possible in the design
of new features.
* The section "Accessibility Implications" is located in the section "User
@@ -162,7 +162,7 @@ uses different tools. This section clarifies the purpose and usage of these tool
potential issue please either propose a solution or write down a short risk
assessment about potential fallout if there would be no solution for the issue."
-* [Testrail](https://testrail.ilias.de)
+* [Testrail:](https://testrail.ilias.de)
* A [test suite dedicated to Accessibility](https://testrail.ilias.de/index.php?/runs/view/566&group_by=cases:section_id&group_order=asc)
is available.
* Test cases are well groomed, easy to carry out and understand.
@@ -173,7 +173,7 @@ uses different tools. This section clarifies the purpose and usage of these tool
* All KS-Entries are tested to make sure they comply with their stated
accessibility rules and the Accessibility Guidelines.
-* [Issue Tracker](https://mantis.ilias.de)
+* [Issue Tracker:](https://mantis.ilias.de)
* Issues can be reported on automatically testable violations of guidelines.
* Issues can be reported on violations of accessibility rules listed in a KS
entry, but also the on the rules themselves if they need improvement.
@@ -181,18 +181,18 @@ uses different tools. This section clarifies the purpose and usage of these tool
* Issues can be reported against soft / non-objective parts of the Accessibility
Guidelines. These require discussion and decisions. Accessibility Guidelines
are to be amended or clarified to become more objective. Tickets of this kind
- are assigned to the UI/UX/A11y expert group.
+ are assigned to the Accessibility and Language Expert Group.
-* [Jour Fixe](https://docu.ilias.de/goto.php?target=wiki_1357_Jour_Fixe_Agendas)
+* [Jour Fixe:](https://docu.ilias.de/goto.php?target=wiki_1357_Jour_Fixe_Agendas)
* Maintainers can put forward their accessibility issues that came up during
implementation as "Development Issues".
- * The Jour Fix can be contacted for resolving discussions/deciding on issues
+ * The Jour Fixe can be contacted for resolving discussions/deciding on issues
among different stakeholders on accessibility questions.
-* [UI Components](../..//src/UI/README.md)
- * The documentation of UI Components encompases a section on accessibility rules.
+* [UI Components:](../..//src/UI/README.md)
+ * The documentation of UI Components encompasses a section on accessibility rules.
* The documentation can be used to lookup of the mechanism of specific parts of
- the UI
+ the UI.
@@ -202,7 +202,7 @@ continuously in an iterative process aiming to push closer towards achieving tho
goals with each iteration. This section shows how we understand our release cycle
as one iteration in the process of enhancing accessibility in ILIAS. The main
responsibility for following those steps listed in this cycle resides by the
-Technical Board supported by the SIG Accessibility and the UI/UX/A11y Expert Group.
+Technical Board supported by the SIG Accessibility and the Accessibility and Language Expert Group.
### Contracted External Beta Accessibility Assessment - November
* Early in the beta phase a formative Accessibility Assessment is carried out by a
@@ -223,20 +223,20 @@ components to make sure accessibility issues are addressed early and continuousl
before merging.
### After-Action Review Accessibility - March
-* After the release the UI/UX/A11y Expert Group organizes an After-Action Review.
-* The is a yearly meeting organized by UI/UX/A11y expert group and open to all
+* After the release the Accessibility and Language Expert Group organizes an After-Action Review.
+* The After-Action Review is a yearly meeting organized by Accessibility and Language Expert Group and open to all
community members.
* After publishing the stable release, the former season is analysed with respect
to accessibility.
-* The UI/UX/A11y expert group draws up a plan for the upcoming season.
+* The Accessibility and Language Expert Group draws up a plan for the upcoming season.
* The Main Question is: How well did our current process and guidelines hold water
during this release?
-* During this phase the UI/UX/A11y expert group reviews und updates the Accessibility
-Guidelines according to possible new guidelines from the WCAG or other major
+* During this phase the Accessibility and Language Expert Group reviews and updates the Accessibility
+Guidelines according to possible new guidelines from the EN 301 549 or other major
developments outside the ILIAS Community.
* The meeting serves as trigger for the Test Case Author for Accessibility to adapt
the test suite.
-* During this phase the UI/UX/A11y expert group reviews processes and roles that
+* During this phase the Accessibility and Language Expert Group reviews processes and roles that
manage accessibility.
### Feature Freeze - April
@@ -244,9 +244,9 @@ manage accessibility.
* Features for Accessibility Improvements may be derived from the After-Action Review.
### Feature Development
-* Feature must adhere to the Accessibility Guidelines
+* Feature must adhere to the Accessibility Guidelines.
* Maintainers go through the Accessibility Checklist (Todo, provide Link) during
-implementation
+implementation.
### Community Testing - November
* In Beta Phase the new release is specifically tested with regard to accessibility.
@@ -257,7 +257,7 @@ implementation
There are some developments we expect, or at least hope, to happen sometime soon.
Since these things are not there yet, we list them in this separate section.
-Please make sure to understand, that these things are no promisses. Their implementation
+Please make sure to understand, that these things are no promises. Their implementation
heavily relies on resources from the community, where labor is even scarcer and
more important than funding. If you want to see some of these things implemented,
consider offering your resources to the [Technical Board](mailto:tb@lists.ilias.de) for
@@ -270,7 +270,7 @@ further advice:
* Documentation of local Development Tools
* All developers are encouraged to make use of simple diagnostical browser
- extensions like lighthouse, HTML Validator or Wave browser extension
+ extensions like lighthouse, HTML Validator or Wave browser extension.
* A document as a common entry point to our accessibility tooling for new
developers and designers exists.
* IILIAS developers and designers can readily use accessibility tooling on
@@ -278,6 +278,6 @@ further advice:
* Forum as Point of Contact
* Inquiries regarding user interface, user experience and accessibility can
- be made via this forum to the UI/UX/A11y Expert Group.
+ be made via this forum to the Accessibility and Language Expert Group.
* The results to this inquiries are public.
- * The Point of Contact is unified with the already existing UI-clinic.
+ * The Point of Contact is unified with the already existing Accessibility and Language Clinic.