User:Lulu-Ann/lalm
Jump to navigation
Jump to search
Entwurf!
"Look and Listen Map" (vorheriger Arbeitstitel "Image'n'Text Map") wird ein barrierefreier Karten- und Routing-Service.
Das Projekt ist Gewinner bei WissensWert 2010, beim Torsten Brand Preis 2011 und beim D-ELINA 2012.
Achtung, zwei Versionen wurden zusammengeführt, darum gibt es doppelte oder widersprüchliche Anforderungen.
Internationalisierung| Title | Requirement | Rationale | Priority | Planned for Version | Requester | Remarks | % done |
|---|---|---|---|---|---|---|---|
| Es soll ein Text-basiertes Online-Straßenkarten-Dienst erstellt werden | Es soll ein Internet-Portal geschaffen werden, in dem Geodaten in Textform barrierefrei genutzt werden können. | 1 | 1 | gestartet | |||
| Der Dienst soll auf den Geodaten von OpenStreetMap basieren. | 1 | OK | |||||
| Der Dienst soll für Blinde barrierefrei benutzbar sein. | 1 | 1 | Test steht aus. | ||||
| Der Dienst soll für Sehgeschädigte barrierefrei benutzbar sein. | 2 | Test steht aus. Bisher noch keine Realisierung von Features für Farbfehlsichtige. | |||||
| Der Dienst soll auch für Sehende benutzbar sein. | 2 | 90% | |||||
| Der Dienst soll möglichst über [Projektname].accessiblemaps.org erreichbar sein. | 3 | Eigene Domains reserviert: www.lalm.de, www.look-and-listen-map.net | OK. | ||||
| Der Dienst soll in deutscher Sprache verfügbar sein. | 2 | Erste Realisierung erfolgt in englischer Sprache. | 0% | ||||
| Der Dienst soll in englischer Sprache verfügbar sein. | 1 | Test steht aus. | |||||
| Der Dienst soll sich leicht in weitere Sprachen übersetzen lassen. | 1 | In Vorbereitung | |||||
| Der Dienst soll es Blinden ermöglichen, fremde Routen im voraus zu erkunden. | 1 | Test steht aus. | |||||
| Der Dienst soll eine Fußgänger-Routing-Funktionalität enthalten. | 1 | 70% | |||||
| Es soll möglich sein, Startadresse und Zieladresse einzugeben, und sich eine Route in Textform anzeigen zu lassen. | 1 | Textbeschreibung noch sehr rudimentär. | |||||
| Es soll möglich sein, sich auf der Route aber auch außerhalb der Route von Entscheidungspunkt zu Entscheidungspunkt zu bewegen, in dem man eingibt, in welche Richtung man sich fortbewegen möchte ("Textadventure-Modus"/"Erkundungsmodus"). | 1 | 0% | |||||
| Im Erkundungsmodus sollen auch Orte von Interesse in der Nähe genannt werden. (amenities) | 1 | 0% | |||||
| Im Erkundungsmodus sollen Orte von Interesse in der Nähe auch dann genannt werden, wenn sie nicht als node sondern als building area in OSM verzeichnet sind. | 1 | 0% | |||||
| Der Dienst soll keine geographische Einschränkung auf ein Gebiet haben (außer der OSM 85°-Grenze) | 1 | Bisher nur Test-Gebiet Detmold | 1% | ||||
| Es soll möglich sein, beim Routen-Typ zwischen folgenden Möglichkeiten zu wählen: Fußgänger (schnellste=kürzeste Route), Fußgänger (sichere Route), Fußgänger (sicherste Route für Blinde), Auto. | 2 | 0% | |||||
| Der Routen-Typ "Fußgänger (sicherste Route für Blinde)" soll - soweit im Datenmaterial vorhanden - gesicherte Straßenquerungen gegenüber ungesicherten bevorzugen, und bei verlängerter Strecke nachfragen, ob der Umweg in Kauf genommen wird. | 2 | 0% | |||||
| Es soll möglich sein, mittels Daten von Transiki beim Routing den öffentlichen Nah- und Fernverkehr einzubeziehen. | 4 | (Transiki ist noch nicht einsatzbereit.) | 0% | ||||
| Es soll die Möglichkeit geschaffen werden, dass Computer-Benutzer ohne Maus und grafisches Interface OpenStreetMap POIs eintragen, löschen oder Informationen hinzufügen bzw. korrigieren. (Barrierefreie Editiermöglichkeit für Blinde und Sehgeschädigte) | 2 | 0% | |||||
| Die Programmierung soll unter einer freien Lizenz stehen. | 1 | tbd | 100% | ||||
| Es soll eine Druckfunktion für Braille Vollschrift in den implementierten Sprachen bereitgestellt werden. | 3 | 0% | |||||
| Es soll eine Druckfunktion für Braille Kurzschrift in den implementierten Sprachen bereitgestellt werden. | 4 | 0% | |||||
| Die Programmierung aller Komponenten soll so erfolgen, daß ohne Aufwand auch barrierefrei bedienbare Entwicklungsumgebungen verwendet werden können. (Mitprogrammier-Möglichkeit für Blinde) | 1 | OK, Test steht aus. | |||||
| Das Portal soll mindestens mit den aktuellen Top 5 Browsern für Windows benutzbar sein. | 1 | Test steht aus. | |||||
| Das Portal soll mindestens mit den aktuellen Top 5 Browsern für PDAs benutzbar sein. | 2 | Test steht aus. | |||||
| Das Portal soll mindestens mit den aktuellen Top 2 Browsern für Linux benutzbar sein. | 1 | Test steht aus. | |||||
| Es sollen mindestens die 50 häufigsten Tags von OSM für Nodes unterstützt werden. | 1 | Test steht aus. | |||||
| Es sollen mindestens die 50 häufigsten Tags von OSM für Ways unterstützt werden. | 1 | Test steht aus. | |||||
| Es sollen mindestens die 20 häufigsten Tags von OSM für Areas unterstützt werden. | 1 | Test steht aus. | |||||
| Es sollen mindestens die 5 häufigsten Tags von OSM für Relationen unterstützt werden. | 2 | 2 | Test steht aus. | ||||
| Das Portal soll mindestens mit den Top 2 kostenlosen Screenreadern benutzbar sein. | 1 | Orca, N.N. | Test steht aus. | ||||
| Das Portal soll mindestens mit den Top 2 nicht kostenlosen Screenreadern benutzbar sein. | 1 | Jaws, N.N. | |||||
| Auf niedriger Zoomstufe soll eine sinnvolle Kartenbeschreibung erfolgen (Städte nennen, die in der visuellen Repräsentation zu erkennen sind.) | 3 | Test steht aus. | |||||
| Titel | Anforderung | Begründung | Priorität | Geplant für Version | Anforderer | Bemerkung | |
| Barrierefreie Entwicklungsumgebung | Es soll ausschließlich mit Tools gearbeitet werden, die Blinden (kostenlos) zugänglich sind oder durch barrierefreie Tools ersetzt werden können. | 1 | 1 | OK | |||
| Integrierbarkeit | Das Portal soll sich in andere Webseiten integrieren lassen, bzw. ein räumlich gezielter Link soll möglich sein. | 2 | 6 | Noch nicht realisiert | 0% | ||
| Weltweite Verfügbarkeit | Das Portal soll weltweit benutzbar sein | Es gibt keinen Grund, die Verwendbarkeit regional zu beschränken. | 2 | 1 | Einschränkung: Keine OSM-Abdeckung jenseits der 85. Breitengrade. | ||
| Einbindbarkeit anderer Geodaten | Es soll möglich sein, andere Geodaten als die aktuellen OSM-Daten einzubinden | z.B. erfundene Daten für Text-Adventures. | 5 | 9 | Grundsätzlich möglich, noch nicht realisiert | 0% | |
| OpenStreetMap Daten nutzen | Das Portal soll mit Geodaten von OpenStreetMap arbeiten. Attribution und Lizenz sind anzugeben. | Die Daten stehen lizenzkostenfrei zur Verfügung, sind aktuell und können von blinden wie sehenden Mitwirkenden korrigiert und ergänzt werden. | 1 | 1 | Test steht aus. | ||
| Barrierefreiheit | Das Portal soll für Blinde und Sehbehinderte vollständig nutzbar sein. Ausnahmen werden spezifiziert. | Anforderung ergibt sich durch die Zielgruppe | 1 | 1 | Test steht aus. | ||
| Barrierefreiheits-Komfortfunktionen | Das Portal soll Invertierung, Schriftgrößeneinstellung, Navigation mittels Tastendruck und weitere übliche Komfort-Funktionen der Barrierefreiheit anbieten. (z.B. nichtsynthetisch gesprochene Bedienungsanleitung) | 1 | 2 | 10% | |||
| Webapplikation / browserbasiert | Das Portal soll im Webbrowser benutzt werden können. Es darf keine Installation von Software erforderlich sein (außer Standardsoftware) | 1 | 1 | OK | |||
| Mobile Benutzung | Es soll möglich sein, das Portal auf einem mobilen Endgerät (Laptop, PDA, Handy) zu benutzen. | 1 | 1 | T9-Eingabe, Visuelle Karte kann dann wegfallen. | |||
| Mobile Benutzung mit GPS | Es soll möglich sein, wenn vorhanden, mittels eines GPS-Gerätes den Standort zu bestimmen. | 9 | 9 | Noch nicht realisiert. | 0% | ||
| Text-Überblick über niedrige Zoomstufe | Es soll möglich sein, sich auch textuelle Beschreibungen für Regionen ausgeben zu lassen, nicht nur auf Straßendetail-Ebene. | 5 | 6 | Noch nicht realisiert | 0% | ||
| Visuelle Karte | Es soll sehr einfach möglich sein, eine visuelle Karte mit Markierung des aktuellen Standorts und der Richtung einzublenden. | Für Debugging-Zwecke und zur Integration sehender Personen bei der Routenplanung. (Barrierefreiheit für Sehende!) | 2 | 2 | 90% | ||
| Visuelle Karte höchster Zoomstufe | Es soll möglich sein, eine visuelle Karte in besonders hoher Zoomstufe anzuzeigen (Höher Zoom 18) | Für Sehgeschädigte | 3 | 3 | Noch nicht realisiert | 0% | |
| Visuelle Karte mit Farbtausch | Es soll möglich sein, die visuellen Karten invertiert und mit anderen Farben darzustellen | Für Farbfehlsichtige | 2 | 3 | Noch nicht realisiert. | 0% | |
| Textbeschreibung | Zu einer angezeigten Position soll jeweils Koordinate , Adresse, PLZ usw. sowie eine Beschreibung der umliegenden Objekte und Wege als Text angezeigt werden. | 1 | 1 | Noch nicht realisiert. | 0% | ||
| Grammatik | Die Ausgabe soll grammatikalisch korrekt erfolgen und für grammatikalisch korrekte Ausgabe in anderen Sprachen vorgesehen sein. | 1 | 1 | Bisher nur Nennung der Tags (englisch) | 1% | ||
| OSM Tags | Mindestens die Top 100 OSM Tags für Punkte, Strecken und Top 10 Relationen sind sprachkorrekt wiederzugeben. | 1 | 1 | 0% | |||
| Außerdem alle Tags, die „Visual Impairment“ kategorisiert sind. | 0% | ||||||
| Außerdem alle Tags des öffentlichen Nah- und Fernverkehrs incl. Taxen usw. | 0% | ||||||
| Erkundungsmodus | Das Portal soll ein „Herumlaufen“ in den Geodaten erlauben, ähnlich in einem Text-Adventure. Mögliche Wege und ihre Richtungen sollen dabei angesagt werden. | 1 | 1 | 0% | |||
| POIs im Erkundungsmodus ansagen | Im Erkundungsmodus sollen abhängig von den Tag-Einstellungen auch POIs in der Umgebung angesagt werden. | 0% | |||||
| Startpunkt-Eingabe | Es soll möglich sein, seinen Startpunkt einzugeben (z.B. als Adresse, als Koordinaten usw.) | 1 | 1 | Als Adresse funktioniert bereits im Testgebiet. | 50% | ||
| Routingmodus | Es soll die Möglichkeit bestehen, zu einem Startpunkt einen Zielpunkt zu ergänzen. Es soll auf Anfrage ein Routing von A nach B berechnet und ausgegeben werden. | 1 | 2 | 50% | |||
| Querungs-Routing | Die Routing-Funktion soll Querungen von Straßen berücksichtigen und nennen. | 1 | 3 | 0% | |||
| Routing-Optionen | Es soll beim Routing möglich sein, zwischen schnellster/kürzester und sicherster Route zu wählen. Dabei sind Straßenquerungen nach ihrer Sicherheit zu bewerten. | Blinde nehmen teilweise Umwege in Kauf, um eine Blindenampel benutzen zu können anstatt einer ungesicherten Querung. | 1 | 3 | 0% | ||
| Komplexe Kreuzungen | Es soll eine sinnvolle Zusammenfassung von komplexen Kreuzungen abgerufen werden können. | 1 | 4 | 0% | |||
| Strecken-Sperrung | Es soll möglich sein, beim Routing bestimmte Strecken oder Bereiche für eine Zeitdauer zu sperren. | z.B. um Baustellen zu umgehen. | 5 | 0% | |||
| Transiki | Für die Benutzung öffentlicher Verkehrsmittel soll eine Anbindung an Transiki bereitgestellt werden. | Öffentliche Verkehrsmittel sind für Blinde unerlässlich | 10 | 10 | Erfordert Projektfortschritt bei Transiki. | 0% | |
| Einbindung von Audio-Routing | Es soll möglich sein, die Routing-Anweisungen im Daisy-Format herunterzuladen und mitzunehmen. | 7 | 0% | ||||
| LoroDux Komplett-Dateierzeugung | Es soll möglich sein, ein Gebiet aufzusuchen und für dieses Gebiet eine fertige LoroDux-Datei incl. Daten und Funktionalität herunterzuladen. | 5 | 0% | ||||
| OSM-Ergänzungs-Funktion | Es soll möglich sein, durch Import von GPX-Dateien POIs hochzuladen und mit Tags zu versehen. | 6 | 0% | ||||
| OSM-Bearbeiten-Funktion | Es soll möglich sein, OSM-Daten zu editieren, z.B. in dem man die Koordinaten verschiebt auf eine per GPX importierte Position. | 6 | 0% | ||||
| LoroDux | Es soll ein Export der Route möglich sein, der von LoroDux eingelesen werden kann. | 4 | Erfordert Funktionalitäts-Ergänzung bei LoroDux | 0% | |||
| Loadstone-GPS-Routen-Export | Es soll ein Export der Route möglich sein, der von Loadstone-GPS eingelesen werden kann. | 4 | Kooperation mit Loadstone-Team ist wünschenswert. | 0% | |||
| Druckfunktion | Es soll möglich sein, die Ausgabe in Kurzschrift und Basisschrift sowie in Schwarzschrift auszudrucken. | 2 | 5 | Achtung, verschiedene Sprachen haben verschiedene Braille-Schrift. | 0% | ||
| Login und Präferenz-Speicherung | Es soll möglich sein, dass sich ein Benutzer auf der Seite registriert, um seine Präferenzen abzuspeichern und beim nächsten Besuch wieder aufzufinden. | 2 | 4 | Farb-Einstellungen | 0% | ||
| Präferenz-Einstellung Richtungsansage | Der Benutzer soll wählen können zwischen Ansage in (absolut:) Himmelsrichtungen, Winkelgrad, Grad auf Uhr sowie (relativ:) Links-Rechts, Winkelgrad, Grad auf Uhr | 1 | 0% | ||||
| Präferenz Bürgersteig-Annahme | Der Benutzer die Möglichkeit haben, die Annahme, ob neben jeder Straße benutzbare Fußwege sind, pro Straßentyp und Gegend selbst einstellen zu können. | 1 | 0% | ||||
| Präferenz-Einstellung Rollstuhl-Routing | Der Benutzer soll die Möglichkeit haben, einzustellen, ob er stufenfreies Routing möchte. | 6 | 0% | ||||
| Präferenz-Einstellung Stylesheet | Der Benutzer soll sich Farben und Schriftgrößen einstellen und speichern können. | 1 | 1 | 0% | |||
| Präferenz-Einstellung Favoriten-Orte | Der Benutzer soll sich mehrere Orte mit Zoomstufen speichern und abrufen können. | 1 | 1 | 0% | |||
| Präferenz-Einstellung Export | Der Benutzer soll sich mehrere Export-Schemas speichern können (z.B. „nach Loadstone, mein Zuhause, Zoomlevel XY) | 5 | 10 | 0% | |||
| Präferenz-Einstellung Sprache | Der Benutzer soll sich eine Sprache voreinstellen können, die für Portal und Exporte benutzt wird. | 1 | 1 | Bisher nur Englisch. | 0% | ||
| Präferenz-Einstellung | Der Benutzer soll sich einstellen können, ob er metrische oder imperiale Maße möchte. | Bisher nur metrisch | 0% | ||||
| Einheiten | Die Einstellung einer Einheit „Schritte“ soll auch möglich sein. | 0% | |||||
| Präferenz-Einstellung Tags | Der Benutzer soll individuell Tags ausblenden können, die ihn nicht interessieren. Standardmäßig sind „Ab 18“-Objekte ausgeblendet. | 2 | 6 | Ausgeblendet wird minage>=18. | 0% | ||
| Präferenz Einstellung Entfernung der angesagten POIs | Es soll möglich sein, sich einzustellen, in welcher Entfernung man POIs im Erkundungsmodus angesagt bekommen möchte. | 0% | |||||
| Außerdem soll der Winkel eingestellt werden, unter welchem vorwärts POIs angesagt werden, Standard ist 180°. | 0% | ||||||
| Alle Screenreader | Das Portal soll mit den gängigen Screenreadern für verschiedene Betriebssysteme zusammenarbeiten. (Top 3 Windows, Top 2 Linux, Top 1 Windows Mobile, Top 1 Symbian). Dabei sollen die Screenreader in den verschiedenen Sprachen getestet werden. | 1 | 1 | Test steht aus. | |||
| Alle Browser (Top 5 Windows, Top 3 Linux, Top 1 Windows Mobile, Top 1 Symbian) | Das Portal soll mit den gängigen Browsern für verschiedene Betriebssysteme zusammenarbeiten | 2 | 5 | Test steht aus. | |||
| Das Portal soll mehrsprachig und mit verschiedenen Einheitensystemen (Metrisch, Imperial) benutzbar sein. | 2 | 3 | Bisher nur englisch, metrisch. | 0% | |||
| Zugriffs-Zähler | Es soll eine Nutzungs-Statistik mit der Veröffentlichung begonnen werden. | 5 | 1 | 0% | |||
| Pressemeldung bei Veröffentlichung | 1 | 1 | 0% | ||||
| Bei Querung sollen Einbahnstraßen angesagt werden | 0% | ||||||
| Die erlaubte Höchstgeschwindigkeit des Querverkehrs soll bei einer Querung angesagt werden. | 0% | ||||||
| Die erlaubte Höchstgeschwindigkeit des Querverkehrs soll bei einer Querung in die Sicherheitsberechnung einbezogen werden. | 0% | ||||||
| Verkehrsberuhigende Baumaßnahmen (Barriers) auf Straßen sollen bei Querung angesagt werden (Verkehrsberuhigung ist vorteilhaft, aber Blumenkübel und Straßen-Huckel sind Stolperfallen) | 0% | ||||||
| Routing: Neben Länge einer Strecke soll auch ein Gefährdungs-Rating bei der Wegeberechnung einbezogen werden: Es sind Strecken mit weniger Querungen zu bevorzugen. | 0% | ||||||
| Routing: Neben Länge einer Strecke soll auch ein Komplexitäts-Rating bei der Wegeberechnung einbezogen werden: Es sind Strecken mit weniger Abbiegungen und Querungen zu bevorzugen. | 0% | ||||||
| Profilbildung: Bei der Benutzung sollen häufig benutzte Wege mitgeloggt und als "bekannt" gekennzeichnet werden. Es soll möglich sein, Strecken manuell im Bekanntheits-Status zu verändern. Bekannte Wege sollen bei der Wegeberechnung bevorzugt werden. | 0% |
Oberfläche
Anforderungen an LALM
| Titel | Anforderung | Begründung | Priorität | Geplant für Version | Anforderer | Bemerkung |
|---|---|---|---|---|---|---|
| Gelbe Schrift auf schwarzem Grund (für maximale Farbfehlsichtigkeit optimal "Achromatopsie") | OK | |||||
| Titel (title-tag): Look and Listen Map - Startseite (An Internationalisierbarkeit denken!) | 50% | |||||
| 1. Titel (h1-tag): Look and Listen Map | OK | |||||
| Text: Diese Seite befindet sich in der Entwicklung. Es funktioniert noch nicht alles. | 0% | |||||
| 2. Feld: Dropdown Sprachauswahl. Werte: 1.Englisch 2. Deutsch 3. Ich möchte beim Übersetzen in eine weitere Sprache helfen 4. Ich möchte Spenden, damit in eine weitere Sprache übersetzt wird. | 0% | |||||
| 3. Tastaturnavigation: Ein Bereich, in dem die Tasten erklärt werden, mit denen man auf dieser Seite Bereiche direkt anspringen kann. Muster: ISCB.de | 0% | |||||
| Link: Was ist das? | Kurzer Einleitungstext auf Deutsch ist vorhanden. | 5% | ||||
| Link: Anleitung | 0% | |||||
| Link: Anmelden oder Registrieren | 0% | |||||
| Link: Sponsoren und Unterstützer | Sponsoren und Unterstützer werden auf der Seite genannt | 5% | ||||
| Link: Spenden | 0% | |||||
| Link: Mailnachrichten abonnieren | 0% | |||||
| Link: Impressum | 100% | |||||
| Bei ausgeschaltetem Java-Script eine Meldung, was dann geht oder nicht geht | Test steht aus. | |||||
| Alle Links, die noch nicht gehen, werden bitte mit dem Anhang (inaktiv) oder (in Entwicklung) gekennzeichnet! |
Generelle Anforderungen an Applikationen für Fehlsichtige
Anforderungen an Grafik von Menschen mit verschiedenen (Farb-)Fehlsichtigkeiten
| Titel | Anforderung | Begründung | Priorität | Bemerkung |
|---|---|---|---|---|
| Rot-Grün | Es sollen keine Rot-Grün-Kontraste verwendet werden, besonders nicht in Pastelltönen. | Durchschnittlich 8% der Männer (DE) sind Rot-Grün-Fehlsichtig | 1 | |
| Blau | Es sollen keine verschiedenen Blautöne verwendet werden. | Blau-Fehlsichtige können verschiedene Blautöne auch bei Helligkeitsunterschieden nicht unterscheiden. | 2 | |
| Hoher Kontrast | Es sollen für Schrift usw. hohe Kontrastunterschiede gewählt werden. | Unter anderem bei Grauem Star erleichtert das das Lesen und Erkennen. | 1 | Nicht das Rad neu erfinden, sondern die erprobten Farb-Kombinationen von deutschen Straßenschildern nehmen. |
| Achromatopsie | Bei weißer Schrift auf schwarzem Grund soll Gelb als Hervorhebungsfarbe benutzt werden. | Achromaten können außer Gelb keine Farben erkennen/unterscheiden. Gelb wird als angenehm empfunden. | 3 | |
| Einheitliche Kontrastrichtung Vordergrund/Hintergrund | Es soll auf einer Seite stets "hell auf dunkel" oder "dunkel auf hell" verwendet werden, jedoch nicht gemischt. | Damit Menschen, die eine der Kontrastrichtungen besser erkennen können, mit schlichtem Invertieren alles erkennen können. | 1 | |
| Keine unnützen Grafiken | Es sollen keine Grafiken als Aufzählungszeichen, als Platzhalter oder als Spacer verwendet werden. Eine Grafik ist dann nicht unnütz, wenn ein sinnvoller, informationstragender ATL-Tag vergeben werden kann. | |||
| Keine unnützen Frames | Frames sollen nur dann benutzt werden, wenn das Frame eine eigenständige einmalige Funktion erfüllt, z.B. als Navigationsbereich. | Frames sind schwieriger zu navigieren mit Screenreader. | 1 | |
| Keine verdoppelten Bereiche | Es soll jeweils nur genau einen Navigationsbereich und nur einen Anzeigebereich geben. Seltener verwendet ist z.B. noch ein Suchergebnisbereich sinnvoll. | Doppelte Navigations-Menüs sind mit Screenreader unauffindbar. | 1 | |
| Title-Tag | Es soll ein geeigneter Title-Tag gewählt werden, der alle Seiten des Anbieters unterscheidet. | Das Umschalten zwischen Tabs / Browserseiten ist sonst ein Ratespiel. | 1 | |
| Druckansicht | Es soll eine Druckansicht geben. Sie darf ohne Farbwahrnehmung oder im Schwarzdrucker nicht unverständlich werden. | Jeder ist am Schwarzdrucker farbenblind. | 1 | |
| Korrekte Sprachauszeichnung | Webseiten sollen die korrekte Sprache angeben | Damit der Screenreader richtig vorliest | 1 | |
| Fremdsprachige Begriffe vermeiden | Fremdsprachige Begriffe sollen vermieden werden (z.B. Login für Anmeldung, Logout für Abmeldung, Website für Webseite...) | Weil der Screenreader das sonst falsch vorliest. | ||
| Camel Case und reine Großschreibung vermeiden. | Es soll korrekte Groß- und Kleinschreibung benutzt werden. | Weil der Screenreader sonst anfängt zu buchstabieren. | 1 | |
| Semantisches HTML | HTML-Tags sollen gemäß ihrer Bedeutung benutzt werden, nicht um Designanforderungen wiederzuspiegeln. Das schließt auch ein, daß Tabellen nicht zu Designzwecken benutzt werden. | Weil ein Screenreader falsch gesetzte Merkmale anders wiedergibt. | 1 | |
| Korrektes HTML | Der HTML-Quellcode soll durch diverse Validatoren auf Richtigkeit getestet werden. | Weil inkorrekter HTML-Code beim Screenreader zusätzliche Probleme erzeugen kann. | 1 | |
| Testen gegen Biene-Kriterien | Webseiten sollen gegen die Kriterien des Biene-Awards getestet und ggf. korrigiert werden. | Weil hier weitere Probleme abgefangen werden. | 2 | |
| Vermeiden von grafischen Captchas | Grafische Captchas sollen vermieden oder durch akustische oder semantische Captchas ersetzt werden. | Grafische Captchas schließen sehbehinderte Benutzer aus. | 1 | |
Liste der bekannten Blindennavigationslösungen: