User:Lulu-Ann/lalm

From OpenStreetMap Wiki
Jump to: navigation, 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:

http://www.bfg-it.de/wiki/Kategorie:Navigation

[1]