Akadálymentességi követelmény-e az érvényes (valid) HTML kód?
A WCAG 2.0 és a WCAG 2.1 szabvány 4.1.1 Parsing teljesítési feltételét nagyon sokan félreértelmezik. Időnként még az akadálymentességgel foglalkozó szakemberek között is akadnak olyanok, akik határozottan állítják, hogy egy weboldal kizárólag akkor felelhet meg ennek a teljesítési feltételnek, vagyis ezen keresztül csak akkor tekinthető akadálymentesnek, ha a weboldal HTML kódja százszázalékosan érvényes, vagy más szóval valid. Nos, én azoknak a táborába tartozom, akik szerint ez nem egészen így van.
Rögtön a legelején szeretném leszögezni, hogy én a szabványos HTML kódolás megrögzött híve és evangelistája vagyok. Mindig minden webfejlesztőt arra biztatok és oktatok, hogy nagyon figyeljen oda a HTML kód érvényességére, mert a technológiai szabványok nem véletlenül léteznek. A valid kód a WCAG szabvány robusztusságra vonatkozó alapelve, és a kompatibilitásra vonatkozó irányelve miatt is nagyon fontos. Ugyanakkor azt is látni kell, hogy nem minden HTML érvényességi hiba okoz a felhasználók számára akadálymentességi problémát. Ezért is bosszant nagyon, ha egy félreértelmezésre épülő akadálymentességi audit eredménye alapján a fejlesztőket olyan jellegű HTML hibák korrigálására is „kötelezik”, amelyeknek közvetlenül nincs semmi közük a WCAG szerinti megfeleléshez.
A 4.1.1 teljesítési feltétel alkritériumai
Ha alaposabban megnézzük a szóban forgó teljesítési feltételt, akkor elsőként azzal szembesülünk, hogy konkrétan nem is a HTML specifikációt említi, hanem általánosságban a webes tartalmakat leíró jelölőnyelvekről beszél. A HTML és az XHTML mellett például az SVG is egy ilyen jelölőnyelv, tehát elvileg a weboldalon található SVG grafikákra is vonatkozik. Köztudott, hogy ezen jelölőnyelvek közös jellemzője a jelölőelemekre (címkékre) épülő szintaktika.
A teljesítési feltétel a webes tartalmat leíró jelölőelemekkel kapcsolatban 4+1 alkritériumot fogalmaz meg, melyek potenciálisan befolyásolhatják a weboldal akadálymentességét is:
1. A jelölőelemek teljes (hiánytalan) nyitó és záró címkékkel rendelkezzenek
Például a <p egy hiányos címke.
Vagy az <img alt=Macska ül az ajtó előtt src="kep.jpg"> kódban az alt attribútum értéke nincs idézőjelek között, így a címke nem minősül teljesnek.
2. A jelölőelemek a vonatkozó specifikációnak megfelelően legyenek egymásba ágyazva
Vitatott kérdés, hogy ez például a HTML esetén csak a szintaktikára vonatkozik-e, vagy a HTML tartalmi modelljére is (lásd HTML Content models).
Például a <button><a href="#">Küldés</button></a> kód szintaktikailag egyértelműen egy hibás beágyazás.
A <button><a href="#">Küldés</a></button> kód szintaktikailag ugyan egy helyes beágyazás, de a button elem tartalmi modellje alapján nem megengedett, hiszen gombon belül értelmetlen egy másik interaktív elemet, mondjuk egy linket elhelyezni.
3. A jelölőelemek ne tartalmazzanak duplikált attribútumokat
Például az <img src="kep.jpg" alt="" alt="Macska"> kódban az alt attribútumból kettő is szerepel, így nem feltétlenül egyértelmű, hogy van-e a képnek alternatív szövege vagy nincs.
Ugyan a teljesítési feltétel nem tesz kivételt, de nagyon nem mindegy, hogy az adott attribútumnak van-e bármilyen közvetlen vagy közvetett kapcsolata az akadálymentességgel. Például egy duplikált class vagy data- attribútumnak valószínűleg nincs, bár nem kizárt.
4. Minden id attribútumérték egyedi legyen
Például az <input type="radio" id="szin" name="szin" value="piros"><input type="radio" id="szin" name="szin" value="fekete"> kódrészletben mindkét rádiógombnak "szin" értékű id attribútuma van, tehát nem lesz egyértelmű, hogy a <label for="szin"> melyik rádiógomb címkéjét definiálja.
Kivétel itt sincs megemlítve, de gyakorlati oldalról nézve ennél a kritériumnál sem mindegy, hogy az egyforma id értékek milyen jelölőelemekhez lettek társítva, és vannak-e egyáltalán a kódban olyan elemek, amelyek kifejezetten erre az id értékre hivatkoznak (például for, aria-labelledby, aria-owns, headers stb. attribútumokon keresztül).
5. A fenti négy kritérium bármelyikétől el lehet tekinteni, ha azt a vonatkozó jelölőnyelv specifikációja megengedi
Például a HTML5 szabvány pontosan definiálja, hogy mely nyitó és/vagy záró címkék opcionálisak (lásd HTML Optional tags).
HTML hibák, amelyek nem kapcsolódnak a 4.1.1 kritériumhoz
A HTML kód érvényességét leggyakrabban különböző validátorokkal szokás tesztelni. A legismertebb például a W3C Markup Validation Service. Ezek a validátorok olyan érvényességi hibákat is listázhatnak, amelyek nem tartoznak a 4.1.1 teljesítési feltételhez. Ilyenek például:
- az ismeretlen jelölelemek
- az ismeretlen attribútumok
- a hibás attribútumértékek
- a hiányzó attribútumértékek
- az elavult jelölőelemek vagy attribútumok
Az ilyen és az ezekhez hasonló érvényességi hibák önmagukban nagyon kicsi eséllyel okozhatnak akadálymentességi problémákat.
A HTML érvényességének ellenőrzésekor tehát alaposan meg kell nézni, hogy a validátor által kijelzett hiba pontosan melyik kategóriába tartozik, és kizárólag az akadálymentesítés miatt nem muszáj rögtön az összeset korrigálni. Persze mindig mérlegeljük, hogy az érvényességi hibák egyéb területeken is problémákat okozhatnak, így adott időtávon belül érdemes mindegyiket kigyomlálni.
A 4.1.1 kritérium szempontjából lényeges hibák kiszűrésére egészen jól használható az említett W3C Validator-hoz készült WCAG Parsing Bookmarklet nevű eszköz is.
Biztosan nem szerepel a WCAG-ban a teljes megfelelés követelménye?
Sokan talán azért gondolják, hogy a WCAG megfeleléshez a HTML kód százszázalékos érvényessége is kell, mert a WCAG szabvány informális mellékletében van egy technológia, ami ezt „sugallja”. A G192: Fully conforming to specifications (magyarra fordítva A specifikációknak való teljes megfelelés) valóban azt mondja, hogy ha az adott jelölőnyelvet teljes mértékben a specifikációjának megfelelően alkalmazzuk, akkor a 4.1.1 teljesítési feltételnek is teljes mértékben eleget teszünk.
Miközben ez az állítás tökéletesen helytálló, mégis ezek a WCAG technikák csak informális ajánlások, azaz közvetlenül nem a formális („betartandó”) szabvány követelményei.
Másrészt a G192 technika leírásában is szerepel, hogy a jelölőnyelvi specifikációknak történő teljes megfelelés csak egy jó gyakorlat, de nem szükséges a WCAG-nak történő megfelelőséghez.
Helló WCAG 2.2, viszlát 4.1.1!
A 4.1.1 teljesítési feltétel még azokból a régi időkből származik, amikor a kisegítő technológiák, például a képernyőolvasó programok maguk elemezték és értelmezték a weboldal HTML kódját. Így ha az elemzés közben valami anomália lépett fel, akkor ez kihatással lehetett a kisegítő technológia működésére, és ezen keresztül az akadálymentes felhasználói élményre is.
De nem csak a kisegítő technológiák, hanem a böngészőprogramok is különbözőképpen értelmezhették a szintaktikailag hibás kódot. Előfordulhatott, hogy az értelmezési anomália a weboldal vizuális megjelenésére abszolút nem volt hatással, ezért a fejlesztők könnyen átsiklottak a hibákon. Ugyanakkor az akadálymentesség ilyenkor is sérülhetett. Megjegyzem, hogy ez ma is ugyanúgy fennáll, ezért is fontos a kódellenőrzés.
A helyzet annyiban változott, hogy manapság a kisegítő technológiák jellemzően már nem közvetlenül a HTML kódot értelmezik, hanem a böngészőprogram által előállított akadálymentességi objektummodellt (Accessibility Object Model – AOM) használják. A kód elemzése tehát döntően a böngészőprogramokra hárul.
És a böngészőprogramok is változtak, hiszen a HTML5 specifikáció megjelenésével a szintaktikailag hibás kódok értelmezésének és korrekciójának mikéntje elvben szabványosítva lett. Vagyis a modern böngészőprogramok a hiányos címkézést, a jelölőelemek helytelen egymásba ágyazását, a duplikált attribútumokat és az egyéb szintaktikai problémákat – a lefektetett elemzési szabályoknak köszönhetően – már többé-kevésbé kiszámítható módon korrigálják. Bár legyünk annyira szkeptikusak, hogy az informatikában a szabványkövető működés soha nem létezik, és nem is fog létezni.
Alapvetően a fenti indokok miatt döntött úgy a W3C, hogy a WCAG 2.2 szabványban már nem fog szerepelni a 4.1.1 Parsing teljesítési feltétel.
Mindez azt jelenti, hogy ha a weboldal kódjában olyan érvényességi hiba van, ami kihat az akadálymentességre, akkor a WCAG 2.2 szempontjából a következmény a lényeges, és nem önmagában az érvényességi hiba, mint hibaforrás. Például a hibás név, a rossz alternatív szöveg, a billentyűzetes kezelhetetlenség stb. Megjegyzem, hogy én jellemzően eddig is ezt az elvet követtem az akadálymentességi auditjaim során. Szinte soha nem volt olyan, hogy kizárólag önmagában a 4.1.1 teljesítési feltételre hivatkoztam volna egy akadálymentességi probléma esetén. Az persze egy más kérdés, hogy a probléma orvoslására rendszerint az érvénytelen kód korrekcióját javaslom.
Sajnos azoknál a projekteknél, ahol a jogszabályi, a pályázati vagy egyéb környezet még a WCAG 2.0/2.1 vagy az EN 301 549 szabvány alkalmazását írja elő, ott a 4.1.1 teljesítési feltétel nem kerülhető meg. Remélem, hogy a cikkemben említett értelmezési szempontok ezekben az esetekben is segítséget nyújtanak majd.