Skip to content

Update: Revise accessibility process documentation #11954

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
Annett7811 wants to merge 1 commit into
base: trunk
Choose a base branch
from
Open

Update: Revise accessibility process documentation #11954

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
156 changes: 78 additions & 78 deletions docs/development/accessibility-process.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand All @@ -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.


<a name="tools"></a>
Expand All @@ -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
Expand All @@ -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.
Expand All @@ -173,26 +173,26 @@ 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.
The KS entry and implementation are amended via the normal KS process.
* 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.


<a name="activities"></a>
Expand All @@ -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
Expand All @@ -223,30 +223,30 @@ 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
* Features for Accessibility Improvements are to be handed in on time.
* 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.
Expand All @@ -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
Expand All @@ -270,14 +270,14 @@ 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
their local machines by help of the documentation.

* 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.
Loading