Transkription:

Klaus Miesenberger: Sprecher, Peter Minarik, von WIENFLUSS, der dort Frontendentwickler und Userinterfacedesigner ist. WIENFLUSS, die sich, wie wahrscheinlich viele oder alle wissen, sehr stark engagieren im Bereich des barrierefreien Webdesigns. Er wird formvollendet präsentieren, aber formvollendet ist auch das Thema, fortgeschrittene Techniken für barrierefreie Formulare. Und was mir ganz besonders gefallen hat, er ist ein Fan der supersimplen Benutzbarkeit und von geschlossenen Tags. Ich kann das nur unterstützen, ich muss an der Uni oft Code evaluieren, anschauen und benoten und geschlossene Tags sind ein gutes Zeichen dafür, für gute und damit meistens auch barrierefreie Codierung. Peter Minarik bitte.

Peter Minarik: Okay, ja auch von mir erst mal einen schönen guten Morgen. Ich freue mich, dass ich die Ehre hab den thematischen Teil zu eröffnen oder einfach als erster dran zu sein. Kurz zu mir, mein Name ist Peter Minarik, ich bin Frontend Developer bei WIENFLUSS und obwohl wie hier jetzt zu lesen ist, das Betreten der WIENFLUSS-Anlage strengstens verboten ist, dreht sich bei uns alles um Zugang.

WIENFLUSS, also wir sind spezialisiert auf Surfen für jeden, manche nennen das auch barrierefreies Web. Und wir sind spezialisiert auf supersimple und klar aufgebaute Websites, die wirklich jeder verwenden kann. Manche nennen das Usability.

Ich schreibe gern, am liebsten in HTML, in CSS und in JavaScript. Manchmal zeichne ich aber auch gerne. Dann handelt es sich meistens um User Interface Design.

Aber genug von mir jetzt. Es geht los, heute soll es nämlich um Formulare gehen. Ich möchte etwas über Formulare erzählen, genauer gesagt über ein kleines, aber feines Formular-Framework, das wir bei WIENFLUSS entwickelt haben, und auch etwas darüber erzählen wie wir jetzt dabei vorgegangen sind.

Anfangen möchte ich aber mit einer kurzen Motivation, denn wenn wir ehrlich sind, dann sind Formulare an sich jetzt schon mal ein ziemlich langweiliges Thema. Das hat einen relativ einfachen Grund, wenn wir Formulare hören, denken wir vermutlich an so etwas, ein relativ großes und komplexes Papierformular oder vielleicht denken wir auch an so etwas, das ist alles sehr ähnlich. Also wir verbinden mit Formularen einfach etwas, das kompliziert ist und unübersichtlich, langwierig.

Und wir wissen oft nicht, was man von uns will. Im Web haben wir uns den Namen aber geborgt, vielleicht wäre es eigentlich besser im Web einen neuen Namen dafür zu finden. Also ich bin nach der Präsentation gern für Vorschläge offen. Im Moment werden wir aber damit vorlieb nehmen müssen, also Formulare im Web. Diese negativen Eigenschaften, die wir mit Formularen verbinden, sollten wir im Web aus einem Grund weglassen, wir begegnen im Web Formularen überall, egal ob wir etwas suchen, ob ein Benutzer etwas in ein Social Network reinstellen möchte oder etwas kaufen möchte, immer ist ein Formular im Spiel. Denn im Web ist das Formular einfach unser Mittel einer Website mitzuteilen was wir machen möchten.

Das heißt im Web habe ich irgendeine Aufgabe, ich möchte zum Beispiel Musik kaufen, ja hier bin ich, hier ist mein Musikstück, und hier möchte ich sein mit meinem Lieblingssong. Und im Web bedeutet das, in allen Fällen eigentlich, ich brauche ein Formular. Und wie das hier jetzt auf der Skizze quasi auch aussieht könnte man meinen, ja das Formular ist ja eigentlich eine Barriere um überhaupt zu meinem Musikstück zu kommen.

Man kann’s aber auch so sehen, dass das Formular überhaupt die einzige Möglichkeit ist zu meinem Musikstück zu kommen und ich möchte natürlich eher die zweite Sichtweise, würde ich bevorzugen. Aber wir können nicht von der Hand weisen, dass Formulare doch eine gewisse Barriere darstellen und wir müssen uns einfach bemühen diese Barriere so gering wie möglich zu halten. Ja ich hoffe wir sind jetzt alle motiviert. Yes, dann kann’s losgehen.

Ja, am Anfang, wie sollten Formulare sein. Ganz kurz, was wollen wir überhaupt, was ist unser Ziel. Unser Ziel ist, dass wir die Benutzer an die Hand nehmen, wenn wir sie durch das Formular führen. Das beginnt erst einmal damit zu planen, das Formular zu planen, welche Felder sollen hinein. Bei jedem Feld muss ich mir überlegen, ist es überhaupt notwendig, ist es zu diesem Zeitpunkt notwendig es abzufragen oder im Idealfall habe ich die Daten, die ich hier abfrage, nicht vielleicht schon, sind sie nicht sowieso schon vorhanden. Ein weiterer Punkt, den ich mir überlegen kann ist, kann ich vielleicht große Teile des Formulars zuerst mal ausblenden, sind sie optional, blende ich sie erst ein, wenn ich sie brauche. All diese Teile gehören quasi zur Planung des Formulars. Etwas was wir natürlich nur schwer in ein Formular-Framework eingießen lassen können, aber sie sind mindestens genauso wichtig.

Und beim zweiten Teil geht es jetzt quasi schon um das Ausfüllen der Formulare. Und aus BenutzerInnensicht dreht sich alles um Fehler bei Formularen. Das klingt vielleicht etwas komisch, aber wenn wir es schaffen, dass die Benutzerin fehlerfrei durch das Formular kommt, dann sind wir am Ziel. Und um das zu erreichen gibt es quasi zwei große Eckpfeiler aus unserer Sicht. Wir müssen Klarheit schaffen, wir müssen im Formular soviel Klarheit schaffen, dass es erst überhaupt zu gar keinen Fehlern kommt. Und zweitens, da es uns wahrscheinlich nicht immer gelingen wird oder gar nicht gelingen kann, wenn diese Fehler auftreten, dann sie so schmerzlos als möglich zu gestalten für die BenutzerIn. Das war’s zur Einleitung.

Wie sind wir das jetzt angegangen, wie haben wir unseren Framework erstellt. Ganz kurz noch zu Anmerkungen dazu. Erstens die Zielgruppe, die Zielgruppe unseres Frameworks ist natürlich immer die Endbenutzerin, also eine der Zielgruppen, das ist klar. Aber da es sich eben nicht um ein einzelnes Formular handelt, sondern um Formular-Framework ist unsere andere Zielgruppe auch Leute, die Formulare erstellen in HTML. Das können wir selber sein oder das können andere Leute sein, die unser Framework verwenden. Und das hat ein paar Implikationen. Also unser Framework sollte natürlich flexibel sein, möglichst modular, aber auch möglichst einfach zu verwenden, das heißt wir wollten das Framework für andere einfach gestalten, sie sollen über HTML vor allem alle möglichen und alle nötigen Optionen einstellen können und kaum Ausflüge ins Java-Script machen müssen zum Beispiel.

Und die zweite Anmerkung ist, dass unsere Umsetzung, unser Framework natürlich nur eine Möglichkeit ist, eine von vielen wie man so ein Framework umsetzen kann. Wir haben uns bemüht überall dort wo es sie schon gibt, Design Patterns und Best Practices anzuwenden. Aber natürlich gibt es immer andere Varianten und es gibt vor allem immer Raum für Verbesserungen. So, jetzt geht’s aber wirklich los. Was wollen wir machen, habe ich schon gesagt, Klarheit schaffen oder anders gesagt Fehler im Vorhinein vermeiden. Zwei Kernfragen hier vielleicht, die man der Benutzerin des Formulars beantworten sollte, wo bin ich gerade im Formular, Stichwort Kontext, und was wollt ihr von mir wissen hier in einem bestimmten Feld. Dazu vielleicht ein beispielhaftes Formular, nur ganz kurz. Wir wollen ein bissel Struktur in das Formular bringen, das heißt bei einem komplexen Formular ist es gut hier gewisse Abschnitte zu definieren, die vielleicht noch mit einer Überschrift zu versehen, damit man einfach etwas Struktur hat.

Wenn wir reinzoomen in einen so einen Abschnitt, dann befinden sich da drin ein paar Felder. Und auch hier ist es manchmal noch ganz nett, wenn ich sagen kann, okay diese Felder hier, die möchte ich vielleicht noch mal kopieren. Ein gutes Beispiel ist zum Beispiel ein Adressfeld, es besteht aus Straße und Postleitzahl und Stadt und was auch immer noch. Und hier kann ich dann sagen, okay das ist eine Adresse. Wenn ich jetzt bei einem einzelnen Feld angelangt bin, dann gibt es ja Felder, die ein sehr gut beschreibendes Label haben, also ein Label, eine Beschriftung eines Input-Felds. Es gibt jedoch auch andere Input-Felder, die uns zuerst überhaupt nicht klar sind.

Und da ist es gut, wenn wir irgendwelche Tipps anbieten können, in dem Fall einen Tooltipp. Ein Tooltipp wird beschrieben als, kommt von W3C, ist dieses Zitat, als ein kontextuelles Popup, das zusätzliche Informationen für ein Element darstellt, das normalerweise sichtbar werden sollte bei Mouseover oder wenn das Element Tastaturfokus erhält. Hier stecken schon zwei wichtige Sachen drinnen, eben wie gesagt Mouseover und Fokus, das heißt wir könnten, also für Mouseover hätten wir zum Beispiel ja das Title-Attribut am Input-Feld. Das wird nachdem man mit der Maus drüber fährt nach einer kurzen Verzögerung sichtbar. Das Problem des Title-Attributs ist allerdings, dass es mit der Tastatur eigentlich nicht erreichbar ist.

Es hat auch noch andere Probleme wie zum Beispiel, dass es in den meisten Browsern glaube ich nicht mit zoomt. Also wenn man die Schriftgröße vergrößert, bleibt das Title-Attribut sehr klein. Deshalb brauchen wir noch ein zweites Element, das bei Tastaturfokus sichtbar wird. Damit wir auch für die Screenreader-Userinnen diese Information weitergeben können gibt es einen Standard, der sich nennt WAI-ARIA, mit dem man HTML um einige Attribute erweitern kann, die eben dem Screen-User helfen sollen zu verstehen was gerade auf der Seite passiert. Und die können wir hier verwenden für unseren Tooltipp, man kann eben diesem Tooltipp, dieser Zusatzinformation eine Role geben, eine Rolle, ein role=“tooltipp”. Und über ein weiteres dieser Attribute, das sich da nennt aria-described-by verbindet man das TextInput-Feld mit diesem Tooltipp. Wir schauen uns das später auch noch an.

Manchmal sind diese Tooltipps, die ja meistens nur ein paar Worte enthalten, aber auch nicht genug. In komplexen Formularen sollte es auch immer eine Hilfe geben. Und eine sehr gute Art der Hilfe ist die Kontexthilfe, das heißt ich binde die Hilfe dort ein, wo ich sie wirklich brauche. Als Standard hat sich hier ergeben, dass man ein Fragezeichen-Icon verwendet, im Idealfall direkt beim Eingabefeld. Und wenn die Benutzerin auf dieses Icon klickt, dann geht irgendwo ein Hilfetext dazu auf. Wichtig bei der Umsetzung von so einer Kontexthilfe ist, dass die Benutzerin während sie die Hilfe liest auch gleichzeitig das Formular ausfüllen kann. Das heißt nicht geeignet sind oft Popups oder anderes. Und auch nicht geeignet sind modale Overlays, das heißt Overlays, die sich komplett über den Screen legen, und man außer dem Overlay nichts mehr sieht. Also technisch gesagt ein nicht modaler Overlay.

Und im Idealfall ist dieser auch noch verschiebbar, damit kann ich möglichst sicherstellen, dass die Benutzerin sich ihn dort hinschieben kann, sodass sie das Feld ausfüllen kann. Auch hier wichtig, die Tastaturfunktionalität nicht zu vergessen, vor allem die Punkte wie öffne ich’s, wie schließe ich’s und was ist mit dem Tastaturfokus. Also wichtig beim Fokus eben, beim Öffnen und Schließen ist, dass ich den Fokus immer zurücksetze, das heißt sobald diese Hilfe geschlossen wird, muss der Fokus, der Tastaturfokus wieder zurückgehen auf das Feld, wo ich hergekommen bin, also in unserem Fall auf das Fragezeichen-Icon.

So, jetzt würde ich sagen schauen wir uns alles mal kurz an. So, ich werde gleich ein bisschen reinzoomen damit Sie es auch besser sehen, aber als erstes vielleicht für den Überblick gar nicht so schlecht. Also wir haben hier ein beispielhaftes Formular, das ist nicht unbedingt sinnvoll, aber es soll in etwa so was sein wie ein Registrierungsformular, vielleicht bei Ihnen im Verein oder so. Ja wie gesagt man sieht hier jetzt mal grob nur die Abschnitte, oben persönliche Daten, dann Kontaktdaten, Accountdaten, Sonstiges, da sind mir die Namen ausgegangen. Und wenn ich jetzt etwas reinzoome, Moment, ja besser, ja dann eben kommen wir zum ersten Punkt quasi den Kontext, nämlich der Benutzerin klar machen, wo ist sie gerade. Und wir haben, hier sieht man unsere zwei Strukturierungsebenen nicht, also es ist der gesamte Abschnitt, auch wenn man das hier am Beamer nicht mehr ganz so gut sieht.

Der gesamte Abschnitt ist hellblau hinterlegt und diese sage ich mal Unterabschnitte sind noch mal in einem anderen Blauton unterlegt. Hier auch eben dieses Beispiel, wir haben den Namen, der besteht in unserem Fall aus drei Feldern, Titel, Vorname, Nachname. Und unser Framework bietet halt die Möglichkeit solche Felder, die zusammen gehören, denen noch mal einen Namen zu geben. Umgesetzt ist es dabei so, die Labels sind in dem Fall Titel, Vorname und Nachname. Name, das Feld darüber ist keine Legend eines Fieldsets, das könnte man so umsetzen, aber das Problem ist, wenn man ein allgemeines Framework machen möchte, die Legends im Fieldset werden vor jedem Label vorgelesen. Und da wir nicht wissen wie lang die sein werden, kann das unter Umständen sehr lästig werden.

Ja, also wenn man hier so durchtabt sieht man, dass immer die ganzen Blöcke hier gehighlightet werden, hier bei der Adresse mit Telefon, besteht aus Vorwahl und Rufnummer, zum Beispiel. Aber es gibt auch einzelne Felder wie zum Beispiel E-Mail, das zu keiner Gruppe gehört. Zum zweiten Teil, über den ich jetzt grade schon erzählt hab, Tooltipps und Kontexthilfe. Ich gehe einfach mal hierhin und zum Passwort. Eines der Probleme des Title-Attributs sieht man hier schon, ich bin ja sehr reingezoomt hier, aber das Title-Attribut ist noch immer in der gleichen kleinen Schriftart.

Es steht hier Passwort mindestens sechs Zeichen. Wenn ich aber jetzt den Tastaturfokus hineinsetze, dann nehmen wir dieses Element, also den Text den Title-Attributs, ebenso ein Element hinein und das bekommt eben wie schon vorher gesagt role=“tooltipp” und aria-described-by, damit ist klar, dass das Feld, dass es zu diesem Feld Passwort gehört. Etwas Ähnliches haben wir hier bei dem Benutzernamen, ein paar Vorschläge, Mausi1978 oder Hasi17. Wenn man noch immer nicht so richtig weiß was man da wählen soll, gibt’s hier auch eine Kontexthilfe.

Also wie gesagt das Fragezeichen-Icon, wenn ich drauf klicke, geht hier die Hilfe auf. Ich demonstrier gleich mal, mit der Tastatur kann man einfach schließen und Escape. Der Fokus geht wieder auf, das Element selbst zurück, also ich kann’s mit Enter wieder aufmachen. Zusätzlich hat’s einen Schließen-Button, auch hier geht der Fokus wieder zurück, ja und ich kann das Element aber auch verschieben, wenn ich grade hier keinen Platz hab, kann ich’s einfach hierher geben und hier eben trotzdem meinen Benutzernamen eingeben. Ja, das war’s fürs erste Mal, ich komm hier noch mal zurück. Okay. So, wir haben jetzt alles getan um unsere Fehler zu vermeiden, aber es wird uns nicht immer gelingen. Deshalb jetzt ein Fehler ist passiert, wir haben ein paar Schäfchen oder Rehlein am Weg verloren.

Und in diesem Fall müssen wir der Benutzerin drei Hauptfragen beantworten können, wo ist der Fehler passiert, warum ist der Fehler passiert und daraus folgend mehr oder weniger, was muss ich tun damit ich den Fehler wieder gutmachen kann. Aus unserer Sicht handelt es sich, damit wir überhaupt mal feststellen können ist ein Fehler passiert, um Validierung. Und hier gibt’s zwei verschiedene Arten, onblur-Validierung und onsubmit. Ich möchte beide kurz durchgehen. Onblur bedeutet direkt nachdem die Benutzerin das Feld verlassen hat, das heißt direkt nachdem der Tastaturfokus aus dem Feld herausgekommen ist wird das Feld validiert.

Sollte ein Fehler auftreten ist der Vorteil hier für die Benutzerin, dass einfach jeder Fehler einzeln präsentiert wäre, er wird sofort erkannt. Und ein weiterer Vorteil ist noch, dass man den Kontext noch kennt oder in der Nähe des Feldes ist, in dem der Fehler passiert ist. Eine andere Möglichkeit wäre theoretisch noch das Feld schon während der Eingabe der Benutzerin zu validieren. Das kann gut funktionieren, aber es ist hier sehr elementar, dass man Timing und die Verzögerung dieser Validierung richtig hinbekommt. Wenn man das nicht richtig hinbekommt, kann es zu noch mehr Verwirrung führen.

Ein gutes Beispiel ist ein Passwortfeld, das eine Mindestlänge hat, und wenn man nicht schnell genug tippt, dann kommt dauernd schon die Fehlermeldung Passwort ist zu kurz, wo man noch nicht mal fertig ist. Eine sehr gute Diskussion zu dem Thema gibt’s auf A List Apart, die haben ein paar Benutzerinnen hergenommen und eben genau ausgetestet welche Variante die beste ist während, kurze Pause, okay. Also A List Apart hat einen Test gemacht, welche Variante quasi die beste ist und sie sind zu dem Schluss gekommen, dass im Allgemeinen die onblur-Validierung am besten funktioniert. Auch hier jetzt wieder, wie schaffen wir es, dass diese Fehlermeldungen beim Screenreaderuser ankommen. Hier gibt’s wieder diese WAI-ARIA-Attribute, die wir einbinden können, drei an der Zahl. Erstens aria-invalid, damit markieren wir das Eingabefeld als ungültig. Role alert bekommt unsere Fehlermeldung, das bedeutet im Endeffekt, dass sie sofort vorgelesen wird egal was der Screenreaderuser gerade macht. Und über „aria-labeled-by“, in dem Fall wird das Eingabefeld mit der Fehlermeldung verknüpft, damit es klar ist, dass die Fehlermeldung zu diesem oder jenem Eingabefeld gehört.

Die zweite Art der Validierung, die so genannte onsubmit-Validierung, da wird das gesamte Formular vor dem Absenden noch mal validiert, also in unserem Fall auch noch mal mit Java-Script, das heißt es wird noch nicht zum Server geschickt, sondern es wird noch vor dem Abschicken geschaut, ob alles passt. Wichtig ist wenn man das so macht, dass man eine Zusammenfassung der Fehler anzeigt, in dem Fall direkt über oder in der Nähe des Submit-Buttons auf jeden Fall. Und diese Zusammenfassung sollte ich möglichst, also bei jeder steht ja die Liste der Fehler drinnen quasi, von dieser Liste sollte ich möglichst einfach zu den einzelnen Feldern, wo diese Fehler passiert sind, gelangen.

Und dann bleibt noch als Validierung, über die serverseitige Validierung, die nicht Teil unseres Frameworks ist, aber die darf man natürlich nicht vergessen. Erstens können wir nicht davon ausgehen, dass Java-Script vorhanden ist und zweitens gibt es gewisse Fehler, die am Server einfach besser zu testen sind, also Stichwort Plausibilitätsprüfung. Oder auch manche Sachen möchte man aus Sicherheitsgründen lieber nicht im Browser testen, sondern lieber am Server. Wichtig wenn man serverseitige Validierung macht, das heißt die Seite lädt neu, dann diese Zusammenfassung auf jeden Fall auch anzeigen, aber diesmal ganz oben, als erstes vor dem Formular noch.

Und auch das Wort Fehler sollte in den Title-Tag der Seite, damit beim Laden der Seite gleich klar ist, ah okay, irgendwas stimmt nicht. So und jetzt schauen wir uns auch die Fehler, die Validierungen an ganz kurz. Okay, wir sehen hier, ich hab zum Beispiel ein paar Pflichtfelder hier in diesem Formular jetzt eingeführt, beim Vornamen und beim Nachnamen.

Ich spring jetzt einfach mal ins Feld hinein und wieder raus und ich sehe, es kommt gleich eine Fehlermeldung und sie verschwindet gleich wieder. Also ein paar Überlegungen zu dieser onblur-Validierung, die wir uns gemacht haben, das erste ist einmal die Positionierung der Fehlermeldung. Wenn man ein Framework macht, dann weiß man nicht genau wie das dann nachher ausschauen wird, das heißt welche Formulare rechts noch Platz haben oder links noch Platz haben. Das heißt man muss irgendeine Position finden, die in den meisten Formularen gut funktioniert und möglichst wenig verdeckt. Und da wir hier gewählt haben, dass wir unsere Labels unterhalb haben, aber manchmal schon auch irgendwelche Bezeichnungen oberhalb, ist es in den meisten Fällen so, dass wenn man die Fehlermeldung oberhalb, ganz möglichst weit rechts beim Feld macht, da die Wahrscheinlichkeit ist, dass man am Wenigsten etwas verdeckt.

Und zusätzlich ist es halt so, wenn ich aus dem Feld wieder herausgehe verschwindet die Fehlermeldung wieder. Das hat den einfachen Grund, wenn ich viele Fehlermeldungen im Formular schon drinnen habe, dann wird das extrem unübersichtlich. Das Feld an sich bleibt aber markiert und hier auch wichtig nicht nur durch Farbe, das heißt nicht nur, eines hat so einen roten Rand und das Label ist in Rot geschrieben, sondern es gibt hier auch noch ein Icon drinnen. Was haben wir hier noch. Also gesteuert wird das Ganze, das ist vielleicht interessant in unserem Formular, eigentlich fast nur durch Klassennamen.

Das heißt man gibt dem Eingabefeld einen Klassennamen, über den dann klar ist, okay dieses Feld sollte ein Pflichtfeld sein wie zum Beispiel hier, so eine class=“required”. Dann weiß unser Java-Script, okay das ist ein Pflichtfeld. Oder wie zum Beispiel hier unten, das Feld E-Mail, das ist kein Pflichtfeld, aber wenn man etwas eingibt, dann wird es validiert darauf, dass es eine gültige E-Mail-Adresse ist. Das funktioniert auch einfach durch einen Klassennamen, class=“email” auf diesem Input-Feld reicht schon, der Benutzername ist wieder ein Pflichtfeld.

Und wenn ich dann hier also schlussendlich glaube fertig zu sein und das hier speichern möchte, gibt’s noch mal eine Validierung aller Fehler, also aller Felder und alle Fehler werden hier in der Zusammenfassung angezeigt. Und es sind einfach Links zu den Feldern selber, also ich kann hier drauf klicken und komme direkt ins Nachnamefeld, ja.

Ganz kurz hier vielleicht, dass ich einmal ein bissel Code herzeige. Wir sehen hier den Fall eines required fields, also eines verpflichtenden Feldes, das wird einfach durch die class required markiert, und das Java-Script geht schon bevor man das überhaupt ausfüllt her und fügt hier noch wieder so ein WAI-ARIA-Attribut hinzu, nämlich aria-required, damit auch der Screenuser weiß, das ist ein verpflichtendes Feld. Passiert dann ein Fehler, kommen ein bisschen mehr Codes hinzu. Bei einem Input-Felder selber sehen wir wie ich vorher gesagt hab aria-invalid ist gleich true, das heißt das Feld wird als ungültig markiert. Aria-labeled-by stellt die Verbindung her zu der Fehlermeldung darunter über die ID. Und in dieser Fehlermeldung wiederum gibt’s eine, also die Fehlermeldung Pflichtfeld ist mit einem role alert markiert, das heißt sie wird dem Screenuser sofort vorgelesen.

Ja, das war’s auch schon mal zu unserem Framework. Noch einen ganz kurzen Ausblick in die Zukunft. Die Zukunft von Formularen, wenn ich jetzt von Zukunft rede, bei HTML heißt es meistens HTML5. HTML5 bringt uns bei Formularen einige Neuerungen, vor allem mal viele neue Input-Types, nicht nur Type-Text für TextInput-Felder, sondern zum Beispiel E-Mail, URL, Search, für Zahlen, Number und Range, viele Datumsfelder, Date, Time, Month und auch eins für Farben zum Beispiel.

Der Vorteil dieser Felder ist, dass wenn ein Browser sie nicht kennt, dann ist der Fallback einfach ein normales Input-Feld mit Type-Text, das heißt man kann’s eigentlich heute schon ganz gut verwenden. Bei einigen Feldern, ich glaub bei dem Datumsfeld muss man noch ein bissel aufpassen, die werden nämlich von den WebKit-Browsern momentan zwar erkannt und sogar validiert, aber davon wird der Benutzerin nix mitgeteilt, dass sie validiert werden. Das kann natürlich extrem verwirrend sein. Ein Vorteil ist zum Beispiel, also eines der Vorteile von diesen Feldern ist, dass auf Systemen, die eine virtuelle Tastatur haben wie zum Beispiel auf einem i-Phone oder einem anderen Smart-Phone eine passende Tastatur angezeigt werden kann.

Wie man hier sieht gibt’s einen Input-Type Number und der Mobile-Safari-Browser zeigt hier schon eine Tastatur an, wo die Zahlen zu sehen sind. Gleiches gilt bei URL zum Beispiel, hier wird wie man unten sieht punkt com und das Slash, also häufig gebrauchte Sachen, angezeigt und auch bei E-Mail, der Klammeraffe da unten. Es gibt noch andere Fälle jetzt aus dem Desktop-Browser, Range, kann man zum Beispiel den Browser als Slider darstellen. Search wird momentan glaube ich im Safari, wird so gestylt wie so eine Suchbox und es bekommt ein kleines X zum Rauslöschen.

Und ganz rechts, das Date, das ist aus dem Opera, das ist mehr oder weniger schon ein automatischer, ohne dass man irgendwas machen muss, ein Datepicker. Schaut also gut aus für unsere Zukunft. Was bietet HTML5 noch, ein required Attribut um Felder gleich als Pflichtfelder zu markieren. Und auch hier sieht man, also die Validierung wird mehr in Richtung Browser wandern, was für uns natürlich eine gute Sache ist, zumindest wenn’s alle richtig machen. Und ja der Support für diese ganzen Features wird natürlich steigen. Im Moment im Desktopbereich vor allem Opera ziemlich gut mit den neuen Input-Feldern. Und der vor kurzem leider erst verschobene Firefox 4, also auf 2011 verschobene, wird aber dann, wenn er kommt, volle Unterstützung für alle HTML-Formularfelder haben. Ja war’s das. Ja das war’s. Gibt’s noch Fragen.

Andreas Hafenscher: Ja, wo finden wir das Framework bitte?

Peter Minarik: Das Framework kann man momentan noch nirgends finden, wir planen aber es herauszubringen aus Teilen von einem anderen Projekt. Und einfach unseren Blog ein bisschen im Auge behalten, wir werden es auf jeden Fall ankündigen, wenn wir das freigeben.

Frage A: Unterstützt das Framework Mehrsprachigkeit auch?

Peter Minarik: Nein, es ist nicht Teil des Frameworks, das kann man natürlich aber einfach einbauen, also in Java-Script könnte man ja einfach, gibt’s ja gängige Best Practices wie man Mehrsprachigkeit einbaut, man bindet einfach je nach Sprache die ausgewählt ist ein Übersetzungsfile ein und kann hier ganz einfach die Strings ersetzen. Ist aber jetzt nicht Teil unseres Frameworks, nein.

Frage B: Auf die Bestimmungen des Bundeskanzleramts der Republik Österreich wurde nicht sehr viel Bedacht genommen oder zumindest in vielen Teilen nicht Bedacht genommen, sagen wir einmal so. Also es gibt keinen Infopart und der Leittext ist nicht links und dergleichen.

Peter Minarik: Was ist nicht links?

Frage B: Der Leittext zum Eingabefeld, das Label.

Peter Minarik: Ah gut, das ist richtig, wobei wo das Label platziert ist, ist glaube ich, ja da gibt’s verschiedenste Diskussionen was jetzt gut ist, was nicht. Neben dem Input-Feld hat zum Beispiel den Nachteil, wenn man in den Mobile-Bereich schaut, kann’s hier schwieriger werden, weil Label und Input-Feld nebeneinander sind und sonst wird es schwieriger. Die Zusammenhänge sind, wir haben uns natürlich viel überlegt zu dem, auch zu Labelplatzierung natürlich und eine Labelplatzierung unterhalb oder oberhalb erlaubt einfach die größtmögliche Flexibilität. Wenn man nicht weiß, was für Formulare jetzt gebastelt werden aus unserem Framework.

Klaus Miesenberger: Vielen Dank sage ich vorerst einmal. Sollte noch eine Frage komme in der Zwischenzeit, ich habe vorher vergessen anzusagen bei der Moderation, dass ich gerne fünf Minuten bevor die Zeit laut Plan abgelaufen ist mit einer gelben Karte, die leider weiß ist, weil der Farbdrucker nicht gegangen ist, bei mir hat gar nichts funktioniert heute, und dann zwei Minuten vorher eine rote Karte, die auch weiß ist, aber es steht zwei drauf, doch Gott sei Dank zweierlei Medien verwendet um es zu verstehen. Vorher stoppen und dass wir dann auch etwas Zeit haben für die Diskussion. Und jetzt frage ich noch einmal, ob es noch eine Frage gibt. Bitte.

Peter Minarik: Darf ich ganz kurz darauf noch hinweisen, falls es noch jemand nicht gesehen hat, WIENFLUSS sucht einen Frontend-Developer, Frontend-Developerin.

Frage C: Ich habe eine Frage, und zwar warum CSS-Klassen, also so was wie aria required könnte man ja auch gleich direkt ins HTML schreiben und nicht erst per Java-Script ersetzen, also grad wenn man das Formular beim ersten Mal sieht. Und jetzt kommt wahrscheinlich Doctype HTML4 nicht validiert, Antwort.

Peter Minarik: Richtig. Ja also bei der Frage geht’s quasi darum, warum wir WAI-ARIA nicht direkt inkludiert haben ins Formular, sondern über Java-Script. Darüber kann man natürlich diskutieren. Eine Möglichkeit wäre auch gewesen als Doctype HTML5 zu verwenden, dann darf man die WAI-ARIA-Attribute direkt einbinden. Mit dem Doctype XHTML Strict darf man das nicht. Und es würde auch nur einen Teil betreffen, also zum Beispiel wenn ich während der Validierung dann aria-invalid, role alert und so weiter einbringe, das könnte ich natürlich sowieso nur mit Java-Script. Und wir verwenden die Klassen ja für Verschiedenstes, also unter anderem für required, aber über die Klassen wird ja auch anderes gesteuert, class email zum Beispiel sagt mir, okay dieses Feld sollte validiert werden auf eine gültige E-Mail-Adresse. Ja danke, das stimmt. Ich habe die Zukunft schon präsentiert, noch haben wir sie nicht eingebaut, ja.

Klaus Miesenberger: Nochmals herzlichen Dank. Ich hab noch einen Punkt vergessen, den ich sagen wollte, der Folgesprecher, wenn wir in der Diskussion sind, wenn Fragen sind, würde ich mich freuen, wenn er einen eigenen Rechner verwendet, dass wir aufbauen können, dass wir nicht zu viel Zeit verlieren. Also wenn der Herr Marco Zehe schon hier wär, ich würde mich freuen, wenn er vielleicht schon versuchen könnte aufzubauen. Wenn keine Fragen mehr sind bedanke ich mich herzlichst für den spannenden Vortrag. Die Bewerbungen wegen eines Frontend-Developers sind dann bitte direkt an den Sprecher zu richten und ich hoffe, dass das Announcement dementsprechend auch zum Erfolg führt. Herzlichen Dank.

Peter Minarik: Ich danke auch.

Bilder von web’n’foto.