Ez a dokumentum hivatott elmagyarázni az akadálymentesítési problémákkal kapcsolatos alapokat, és irányelveket ad az OTRS-ben való közreműködéshez.
Az akadálymentesítés egy általános kifejezés annak leírásához, hogy egy termék, eszköz, szolgáltatás vagy környezet milyen mértékben érhető el a lehető legtöbb ember által. Az akadálymentesítés tekinthető úgyis mint „képesség a hozzáféréshez”, és néhány rendszer vagy dolog lehetséges előnyeként. Az akadálymentesítés gyakran a fogyatékkal rendelkező emberekre és a dolgokhoz való hozzáférésük jogára összpontosít, gyakran kisegítő technológiák használatán keresztül.
A webfejlesztés környezetében akadálymentesítéskor a sérült embereknek a webes felületekhez való teljes hozzáférés engedélyezésén van a hangsúly. Például az emberek ezen csoportja részlegesen látássérült vagy teljesen vak embereket tartalmazhat. Míg az előbbiek továbbra is képesek részlegesen használni a grafikus felhasználói felületet, addig az utóbbiaknak teljes mértékben a kisegítő technológiákra kell támaszkodniuk, az olyan szoftverekre, amelyek felolvassák számukra a képernyőt (képernyőolvasók).
A sérült felhasználóknak történő hozzáférés engedélyezése az OTRS rendszerekhez önmagában indokolt cél. Tiszteletet tanúsít.
Továbbá az akadálymentesítési szabványok teljesítése egyre inkább fontossá válik az állami szektorban (kormányzati intézményeknél) és a nagyvállalatoknál, amely mindkettő az OTRS célcsoportjához tartozik.
Ez nagyon egyszerű. Tegyen úgy, mintha vak lenne.
Ne tegye a következőket:
ne használja az egeret
ne nézzen a képernyőre
Ezután próbálja meg az OTRS-t csak egy képernyőolvasó és a billentyűzet segítségével használni. Ez ötletet adhat arra, hogy mit fog érezni egy vak ember.
Amíg a kereskedelmi képernyőolvasók - mint például a JAWS (talán a legismertebb) - nagyon drágák lehetnek, léteznek nyílt forrású képernyőolvasók, amelyeket telepíthet és használhat:
Most már nincs többé mentsége. ;)
Ez a szakasz csak hivatkozásként szolgál, nem kell magát a szabványokat áttanulmányoznia ahhoz, hogy képes legyen akadálymentesítési problémákon dolgozni az OTRS-ben. Megpróbáljuk kigyűjteni a fontos irányelveket ebben a dokumentumban.
Ez a W3C szabvány általános irányelveket ad ahhoz, hogyan hozhatók létre akadálymentes weboldalak.
A WCAG az akadálymentesítési támogatás különböző szintjeivel rendelkezik. Jelenleg az A szint támogatását tervezzük, ugyanis az AA és az AAA olyan kérdésekkel foglalkozik, amely nem tűnik fontosnak az OTRS-nél.
Ez a szabvány foglalkozik a statikus tartalom eltolásából eredő különleges problémákkal a dinamikus webalkalmazásoknál. Olyan kérdésekkel foglalkozik, mint például hogyan értesülhet a felhasználó az AJAX kérésekből eredményezett felhasználói felület változásairól.
Cél: a felhasználónak megjelenő összes nem szöveges tartalomnak legyen szöveges alternatívája, amely ugyanazt a célt szolgálja. (WCAG 1.1.1)
Nagyon fontos megérteni, hogy a képernyőolvasók csak a szöveges
információkat és az elérhető metaadatokat tudják megjeleníteni a
felhasználónak. Hogy egy példát mondjunk, amikor egy képernyőolvasó a
<a href="#" class="CloseLink"></a>
hivatkozást látja, akkor csak a „hivatkozást” tudja felolvasni a
felhasználónak, nem a hivatkozás célját. Egy apró fejlesztéssel
akadálymentessé válhat: <a href="#" class="CloseLink"
title="Felületi elem bezárása"></a>. Ebben az esetben a
felhasználó a „hivatkozás felületi elem bezárása” szöveget hallhatja, íme!
Fontos, hogy a szöveget mindig a leginkább „beszédes” módon fogalmazza meg. Egyszerűen képzelje el, hogy csak ennyi információval rendelkezik. Segíteni fog önnek? Képes megérteni a célját pusztán hallás után?
Kövesse ezeket a szabályokat, amikor az OTRS-en dolgozik:
Szabály: Ahol csak lehetséges, használjon beszédes szövegeket, és fogalmazzon meg valódi, érthető és pontos mondatokat. A „Felületi elem bezárása” sokkal jobb mint a „Bezárás”, mert az utóbbi fölösleges.
Szabály: A hivatkozásoknak mindig legyen vagy olyan
szöveges tartalma, amelyet a képernyőolvasók kimondanak (<a
href="#" >A bejegyzés törlése</a>), vagy
title attribútuma (<a href="#"
title="Felületi elem bezárása"></a>).
Szabály: A képeknek mindig legyen alternatív szövege,
amely felolvasható a felhasználónak (<img src="house.png"
alt="Fénykép egy házról" />).
Cél: lehetővé tenni a felhasználónak, hogy könnyen navigáljon az aktuális oldalon és az egész alkalmazásban.
A title címke az első dolog, amit a felhasználó hall a
képernyőolvasótól, amikor megnyit egy weboldalt. Az OTRS-nél mindig csak
egyetlen h1 elem van az oldalon az aktuális oldalt
jelezve (a title elemből vett információ egy részét
tartalmazza). Ez a navigációs információ segít megérteni a felhasználónak,
hogy éppen hol van, és mi az aktuális oldal célja.
Szabály: Mindig pontos címet adjon az oldalnak, amely lehetővé teszi a felhasználónak annak megértését, hogy jelenleg éppen hol van.
A képernyőolvasók képesek a HTML beépített dokumentumszerkezetét használni
(címsorok h1 és h6 között) egy
dokumentum szerkezetének meghatározásához, és lehetővé tenni a
felhasználónak, hogy egyik szakaszról a másik szakaszra ugorjon. Azonban ez
nem elegendő egy dinamikus webalkalmazás szerkezetének kifejezéséhez. Ez az,
amiért az ARIA számos olyan „iránypont” szerepet határoz meg, amelyek
megadhatók az elemeknek, hogy jelezzék a navigációs jelentésüket.
A HTML dokumentumok érvényességének megtartásához a role
attribútumok (ARIA iránypont szerepek) nincsenek közvetlenül a forráskódba
beszúrva, hanem olyan osztályok által kerülnek beszúrásra, amelyeket később
az OTRS.UI.Accessibility osztályban lévő JavaScript
függvények fognak használni a megfelelő role attribútumok
beszúrásához a csomópontba.
Szabály: Használjon WAI-ARIA iránypont szabályokat a tartalom szerkezetbe foglalásához a képernyőolvasók számára.
Reklámcsík: <div
class="ARIARoleBanner"></div> helyett <div
class="ARIARoleBanner" role="banner"></div> lesz
Navigáció: <div
class="ARIARoleNavigation"></div> helyett
<div class="ARIARoleNavigation"
role="navigation"></div> lesz
Keresőfunkció: <div
class="ARIARoleSearch"></div> helyett <div
class="ARIARoleSearch" role="search"></div> lesz
Fő alkalmazásterület: <div
class="ARIARoleMain"></div> helyett <div
class="ARIARoleMain" role="main"></div> lesz
Lábléc: <div
class="ARIARoleContentinfo"></div> helyett
<div class="ARIARoleContentinfo"
role="contentinfo"></div> lesz
A <form< elemeken belüli navigációnál szükséges a
fogyatékos felhasználónak tudnia, hogy mi az egyes beviteli elemek
célja. Ezt el lehet érni a szabványos HTML <label>
elemek használatával, amelyek kapcsolatot hoznak létre a címke és az űrlap
elem között.
Amikor egy beviteli elem megkapja a fókuszt, akkor a képernyőolvasó általában fel fogja olvasni a hozzá kapcsolt címkét, így a felhasználó hallhatja annak pontos célját. További előnye a látó felhasználóknak, hogy rákattinthatnak a címkére, és a beviteli elem meg fogja kapni a fókuszt (különösen jelölőnégyzeteknél hasznos például).
Szabály: Adjon meg <label>
elemeket az összes űrlapelem (input,
select, textarea) mezőhöz.
Példa: <label for="date">Dátum:</label><input
type="text" name="date" id="date"/>
Cél: lehetővé tenni a felhasználónak, hogy az összes kölcsönhatást végrehajtsa pusztán a billentyűzet használatával.
Miközben technikailag lehetséges kölcsönhatásokat létrehozni JavaScript
segítségével tetszőleges HTML elemen, ezt korlátozni kell azon elemekre,
amelyekkel a felhasználó kölcsönhatásba léphet a billentyűzet
használatával. Különösen azt kell lehetővé tenni számukra, hogy fókuszt
adjanak az elemnek, és kölcsönhatásba lépjenek vele. Például egy felületi
elemet ki-be kapcsoló nyomógombot nem egy JavaScript
onclick eseményfigyelővel összekötött
span elem használatával kellene megoldani, hanem egy
a címkének kellene lennie (vagy tartalmaznia kellene),
hogy világossá tegye a képernyőolvasónak, hogy ez az elem kölcsönhatást
okozhat.
Szabály: A kölcsönhatásoknál mindig olyan elemeket
használjon, amelyek megkaphatják a fókuszt, mint például
a, input, select és
button.
Rule: Győződjön meg arról, hogy a felhasználó mindig képes-e azonosítani a kölcsönhatás természetét (nézze meg a szabályokat a nem szöveges tartalommal és az űrlapelemek címkézésével kapcsolatban).
Cél: Tudatni a felhasználóval a dinamikus változtatásokat.
Az akadálymentesítési problémák egy különleges területe a dinamikus változtatások a felhasználói felületen, amelyeket JavaScript vagy AJAX hívások okoznak. A képernyőolvasó nem fog beszélni a felhasználónak a változtatásokról különleges óvintézkedések nélkül. Ez egy bonyolult téma, és még nem lehet itt teljesen elmagyarázni.
Szabály: Mindig használja az
OTRS.Validate érvényesítő keretrendszert az űrlap
érvényesítéséhez.
Ez biztosítani fogja, hogy a hiba buboréksúgókat felolvassa a képernyőolvasó. Ily módon a vak felhasználó a) megtudja azt az elemet, amelynek hibája van, és b) kap egy szöveget, amely leírja a hibát.
Szabály: Használja az
OTRS.UI.Accessibility.AudibleAlert() függvényt, hogy
értesítse a felhasználót az egyéb fontos felhasználói felületet érintő
változtatásokról.
Szabály: Használja az OTRS.UI.Dialog
keretrendszert a kizárólagos párbeszédablakok létrehozásához. Ezek már
optimalizálva vannak az akadálymentesítéshez.