Barrierefreiheit in TYPO3 – Ein umfassender Leitfaden

Konfigurierbarer Zugänglichkeitscheck für TYPO3-Inhaltselemente und Erweiterungsaufzeichnungen.

• Ziel: Sicherstellung der Barrierefreiheit durch regelmäßige Überprüfungen von Inhalten.
• Vorteile:
  • Bietet anpassbare Prüfungen zur Überwachung der Barrierefreiheit in TYPO3.
  • Ermöglicht Redakteuren die Identifizierung und Behebung von Zugänglichkeitsproblemen.
  • Unterstützung für die Einhaltung von Barrierefreiheitsstandards und -richtlinien.

Für weitere Details können Sie die Quelle hier besuchen: https://extensions.typo3.org/extension/uw_a11y_check

Sprachsynthese- und Vorlesesoftware für Inhalte auf der Webseite.

• Ziel: Ermöglicht die Sprachausgabe von Texten auf TYPO3-Websites.
• Vorteile:
  • Integriert einen Online-Screenreader, der Texte in gesprochene Sprache umwandelt.
  • Unterstützt die Barrierefreiheit, indem Inhalte für hörgeschädigte oder sehbehinderte Benutzer zugänglicher gemacht werden.

Für weitere Details können Sie die Quelle hier besuchen: https://extensions.typo3.org/extension/wes_reader

Fügt Abkürzungsfunktionen in CKEditor hinzu.

• Ziel: Verbesserung der Textbearbeitung durch Unterstützung für Abkürzungen.
• Vorteile:
  • Erlaubt das einfache Hinzufügen von Abkürzungen während der Textbearbeitung.
  • Verleiht Redakteuren die Möglichkeit, Texte klarer und präziser zu gestalten.
  • Unterstützt die Einhaltung von Standards für Barrierefreiheit und Lesbarkeit.

Für weitere Details können Sie die Quelle hier besuchen: https://extensions.typo3.org/extension/rte_ckeditor_abbr

Integriert ReadSpeaker WebReader und DocReader-Dienste für Text-to-Speech.

• Ziel: Ermöglicht Sprachfunktionen und Dokumentenlesedienste auf TYPO3-Websites.
• Vorteile:
  • Bietet die Sprachausgabe von Inhalten in über 30 Sprachen mit mehr als 50 verschiedenen Stimmen.
  • Unterstützt die Zugänglichkeit für hörgeschädigte oder sehbehinderte Benutzer.
  • Ermöglicht das direkte Vorlesen von Texten und Dokumenten, wie PDFs, direkt auf der Webseite.

Für weitere Details können Sie die Quelle hier besuchen: https://extensions.typo3.org/extension/t3readspeaker

A user story should always be written in the shortest possible sentences and in simple words. This ensures that all colleagues involved can understand it, even without expert knowledge. The formulation is always done from the perspective of the customer or user. It is important to name a real benefit.

In particular, the story should highlight who wants what and why. The cornerstones of the question "who", "what", and "why" are to be relatively freely assigned a concrete user or role (who), a fact or function (what), and a reason or value (why) according to the respective context. This results in the following basic sentence structure when writing a user story: As (user), I want (function) to achieve (value). In this context, important terms are Epic Agile and Story Mapping Agile. User stories are collected in agile epics. These collections describe requirements in higher levels of abstraction. The user stories here form the individual steps that users or customers go through until they complete an Epic. To create an agile user story mapping, rough process and work steps are recorded individually in epics and presented in a visual user story template. Using such a visualized user story mapping, the specific requirements can be worked through very clearly. The planning of tasks with regard to the achievement of the respective goal can thus be better estimated and precisely compared at any time of the development using the map. Deviations can be detected as quickly as possible and a prompt, targeted response can be made.

An important question when creating user stories is: How do you correctly estimate the corresponding effort? The short answer is: in person days or with story points. With story points, it is not primarily about the time required for a user story, but about recording its structural properties. These in turn can be used to determine the effort required. To do this, the team first defines a criterion or a combination of various criteria. A typical criterion is complexity. When using person days, all necessary work is identified and summed up. Often a user story of medium size serves as a reference here. The estimate is then made in comparison to this reference.

If user stories are too large, they need to be split to be able to realize them within a sprint. How to split should be strictly based on the value of the user ("As a [user], I want[feature] to achieve [value].") and not on the technology.

The process is optimally done as a team. This allows avoiding unnecessary dependencies between user stories, early description of solutions, and excessive production of less solution-oriented spike stories.

Acceptance criteria help to determine whether user stories have been successfully implemented. Here, key results are defined that are to be fulfilled by the user story. A much-used way to define acceptance criteria is to question keywords. The latter are specifically specific verbs, adjectives, and nouns:

• Who does what, when, and where?
• What happens as a consequence of this action?
• What options does the actor have?

Using such W-questions, acceptance criteria are relatively easy to establish.

The INVEST principle supports agile teams in defining whether a good quality user story has been created?

Determining quality or guaranteeing it to a certain extent is important in order to be able to generate maximum benefit from a user story.

Due to the undoubted relevance of this issue, we devote more detailed attention to INVEST below.

User stories should always be independent of each other. In practice, however, this is not always as easy as it first seems. Technical, content-related or functional, time-related or normative or regulatory dependencies regularly emerge. Even different competencies in the team can indirectly lead to dependencies in the realization of user stories.

In order to effectively exclude such and similar dependencies, it helps to perform a visualization in the sense of user story mapping. In the course of this, it should be possible to quickly identify critical points. An alternative method is to document dependencies in separate tables or as supplementary notes.