Nachdem wir nun per Photoshop umrissen haben, was wir mit dem Suchbereich erreichen wollen, machen wir uns an die Erstellung mit HTML und CSS. Wir haben bereits unsere Icon-Schriftart geladen und fügen sie auf der Seite ein. Font Explorer X hilft uns dabei, das richtige HTML-Zeichen für die Lupe anzuzeigen.
Wir fügen die Markierung in unsere Header-Include-Datei ein und starten eine brandneue Sass-Datei (_search.scss), um den CSS-Code für diesen neuen Bereich zu schreiben. Wir stellen sicher, dass CodeKit von dieser neuen Datei weiß. Leider dauert es in diesen frühen Screencasts manchmal eine Weile, bis CodeKit aktualisiert wird, was ich später darauf zurückführe, dass ich ein bestimmtes Projekt mit einfach zu vielen Dateien darin habe. Sie können dies beheben, indem Sie einfach das Verzeichnis, das CodeKit beobachten soll, einschränken.
Wir positionieren den Suchbereich absolut im Header, sodass er rechts und oben im Hauptinhaltsbereich platziert wird. Wir passen Größe und Platzierung der Lupe an, indem wir speziell auf das Icon abzielen. Wir positionieren die Elemente mit Prozentangaben, damit sie sich gut in unser responsives Design einfügen. Wir fügen auch :hover- und :focus-Zustände hinzu, damit deutlich wird, dass man darauf klicken kann.
Wir schließen ab, indem wir etwas JavaScript schreiben, das den Suchbereich öffnet und schließt. Wir hätten die Animationen direkt im JavaScript haben können (da wir jQuery verwenden), aber stattdessen ändern wir nur Klassennamen im CSS. Das ist, was ich gerne als "zustandsbasierte CSS" bezeichne, bei der JavaScript lediglich Klassennamen steuert, die den Zustand der Seite (oder des Bereichs) deklarieren, und CSS bestimmt, wie die Seite in diesem Zustand aussieht (und wie sie dorthin gelangt). Das bedeutet, dass wir Dinge wie Übergänge in CSS machen, was meiner Meinung nach dort hingehört und langfristig weitaus besser ist (d. h. CSS-Übergänge sind hardwarebeschleunigt, während JavaScript-Übergänge es nicht sind, sondern nur schnelle Iterationen von Inline-Styles sind).
Hier kommt der Barrierefreiheits-Typ ;)
Hier sind ein paar Ideen, um den Suchbereich barrierefrei zu gestalten
1.) Verwenden Sie das ARIA-Landmark-Suchattribut für das `section`-Element.
2.) Umschließen Sie das Icon-Span mit einem
<a>-Element für den nativen Tastaturzugriff.HINWEIS: Im Moment können Sie nicht einfach das Attribut
tabindex="-1"verwenden, damit Sie trotzdem nicht auf den "Button" klicken können.3) Setzen Sie einen beschreibenden Titel für das Icon/den Button. Dies hilft Benutzern mit Sehschwäche/Zoom/älteren Nutzern/kognitiv eingeschränkten Nutzern, die das Icon nicht interpretieren können.
4) Da es sich nicht um einen normalen Link handelt, verwenden Sie
role="button", damit Screenreader ihn als Button und nicht als Link ankündigen.5) Machen Sie, was Sie mich gelehrt haben. Verwenden Sie
aria-hidden="true"für das Icon-Span.6.) Fügen Sie eine barrierefreie Beschreibung für den Button für Screenreader hinzu.
Das war's für den Button.
Nun zum eigentlichen Feld und den Kategorien
7.) Um zu verhindern, dass Screenreader nur "Textfeld" sagen und stattdessen "Suchen, Textfeld" oder sogar "Foren durchsuchen, Textfeld" sagen...
Mir läuft die Zeit davon, um Codebeispiele zu zeigen, aber die Idee ist, ein
<label id="search-label" class="screen-reader">Suchen</label>irgendwo zu platzieren und auch das Attributaria-labelledby="search-label"auf das<input/>-Element für die Suche anzuwenden. Und mit etwas jQuery-Magie die Kategorien dynamisch hinzuzufügen, indem Radio-Buttons anstelle von Links für die verschiedenen Abschnittslinks verwendet werden und dann die ID dieser Kategorie hinzugefügt wird, wie z. B.aria-labelledby="search-label search-forums".Ich hoffe, alles ergibt Sinn, oder senden Sie mir einen Tweet an @DanielGoransson ;)
Na klar! Das nenne ich eine Code-Kritik! Ich werde jeden einzelnen Punkt durchgehen und ihn integrieren.
Tolle Infos, Daniel, hättest du noch Leseempfehlungen, insbesondere zu Punkt 7.