Ich sehe eine Diskrepanz in der Anzeige am unteren Rand und in der Seitenleiste (siehe Bild). Es scheint mir, dass der Zähler am unteren Rand nie zurückgesetzt wird, wenn man die Punkte die am Seitenrand stehen berichtigt hat. Status der Prüfung auf Barrierefreiheit wird beim Einfügen von neuem Text immer weiter erhöht, auch wenn diese Fehler dann verbessert werden.
Verwendetes Betriebssystem: Sequoia 15.7.4
LibreOffice:
Version: 25.2.4.3 (AARCH64) / LibreOffice Community
Build ID: 33e196637044ead23f5c3226cde09b47731f7e27
CPU threads: 8; OS: macOS 15.7.4; UI render: Skia/Raster; VCL: osx
Locale: de-DE (de_DE.UTF-8); UI: de-DE
Calc: threaded
An und Ausschalten der Automatischen Barrierefreiheit etc bringt keine Änderung des Verhaltens.
Der Screenshot ist nicht hilfreich.
Kannst du die Datei auf 3 Seiten kürzen, so dass das Problem noch nachvollzihbar ist und hier hochladen?
In welchem Dateiformat speicherst du?
Ansonsten mal testen:
Menü Hilfe>Im abgesicherten Modus neu starten.
Fehler?
Lieber Hrbrgr,
Danke für Deine Antwort. Leider verstehe ich Deine Antwort nicht. Wahrscheinlich fiel es mir zu schwer, das Problem anschaulich darzustellen. Entschuldigung. Es geht um LibreOffice Writer, der am unteren Rand das Zeichen für die Barrierefreiheit zeigt, und wenn man mit der Maus darüber fährt einem die Anzahl der gefundenen Probleme anzeigt. Siehe meinen eingezeichneten Kreis in dem Bild. Klickt man dort an zeigt sich in der Seitenleiste die “Prüfung auf Barrierefreiheit” mit den entsprechenden Fehlern, diese kann man anklicken und kommt im Dokument zu dem entsprechenden Fehler, den man dann lösen kann. Hier wurden alle gelöst bis auf einen. In der geöffneten Datei gab es bestimmt nicht mehr als 100 Probleme die gelöst wurden, der Zähler setzt sich nur nicht zurück, auch wenn ersichtlich ist, dass nur ein Fehler noch vorhanden ist. (Siehe meine Bemerkung unter dem Kreis). Sichtbar ist im Bild .odt, aber es ist auch bei Vorlagen .ott (ODF-Textdokument, auch bei ODF-Textdokumentvorlage, andere nicht ausprobiert, sollte aber identisch sein).
Nein. Ich verwende mal einen Autovergleich: Derzeit hast Du in einer Werkstatt angerufen und gasgt, dass das Auto immer mal “klonk-klonk” zischen dem ganzen “brumm-brumm” macht.
.
Egrebnis ist eine Antwort nach dem Muster:
- könnte ein größeres Problem sein oder etwas einfaches. Um genaueres zu sagen muss der Wagen mal in der Werkstatt vorgestell werden bzw. in der EDV eine Datei zum Testen hochgeladen werden
- Nachgeschoben schon mal Fragen, die typische Problemkreise ansprechen, hier das Speicherformat (.odt) und die Sache mit dem Benutzerprofil.
.
Uum Thema Benutzerprofil: Dort werden alle Einstellungen gespeichert. Um Auszuschliessen, dass irgendeine Einstellung im Profil stört, sollte man Probleme im safe-Mode prüfen. Sonst kann es sein, dass diejenigen, die die Kopie der eventuell hochgeladenen Datei untersuchen keine Probleme finden, weil der Fehler im Profil liegt.
(Im obigen Beispiel wäre das ein Fehler am Anhänger, wobei das Auto dann ohne Anhänger in die Werkstatt gebracht wird…)
PS: Näheres zum Nutzerprofil und Safe-Mode:
https://wiki.documentfoundation.org/UserProfile/de
Ich habe einmal den folgenden Test gemacht:
Leeres Writer Dokument erstellt.
Dann erschienen bei der Prüfung der Barrierefreiheit 4 Probleme.
Ein Problem war die Absatzvorlage “Verzeichnis” (eine Standardvorlage des Systems), bei der die Sprachangaben fehlten. Das habe ich korrigiert.
Weder auf der Seitenleiste noch in der Anzeige unten im Dokument wurde aber diese Korrektur wahrgenommen. Stand weiter auf “4”.
Erst nach dem Abspeichern, Schließen und Neuaufrufen wurde der Zähler auf 3 zurück gesetzt.
Ich würde da eine Aktualisierung nach der Änderung in der Seitenleiste erwarten.
.
Drollig finde ich 2 weitere Fehler:
- Eigenschaft “Name” des Hyperlinks fehlt
- Verknüpfungen in der Kopf- oder Fußzeile vermeiden
Wohl gemerkt: Die Datei ist bis auf eigene Formatvorlagen (Standardvorlage bei mir) leer.
.
Nicht verändern lässt sich ein Fehler der fehlenden Sprache in den Formatvorlagen, wenn eben die Vorlage dafür gedacht ist, keine Sprache darzustellen sondern Code (in meinem Falle; SQL-Code). Da ist jede Sprache überfordert und der Code wird bei Sprachvorwahl einfach komplett mit den schönen roten Schlängellinien versehen.
Das habe ich jetzt mit einer Umänderung der Sprache auf [Unbestimmt] geregelt bekommen.
.
System hier:
Version: 26.2.3.2 (X86_64)
Build ID: 70e089b17412e4cb7773e41413306b17a2328c34
CPU threads: 6; OS: Linux 6.4; UI render: default; VCL: kf5 (cairo+xcb)
Locale: de-DE (de_DE.UTF-8); UI: de-DE
Calc: threaded