Hírek

Aktív projektek

Utolsó frissítés: 2026. október 31.

Folyamatban

v3: Teljes körű minőségbiztosítási csomag

2026. szeptember 27.

Bemutató a DrupalCon Europe 2026 rendezvényen

Főbb új funkciók

• A tesztmag egyesítése a Sa11y-jal. Az új, közösen fejlesztett szabálykészlet fejlesztői tesztekkel, kontrasztellenőrzéssel és olvashatósági pontozással egészíti ki a tartalomra vonatkozó alapszabálykészletet.
• Többnyelvű támogatás
• Egyedi szabályépítő
• Vezérlőpult-karbantartó eszközök
• Egy webhely-feltérképező eszköz új eredmények felvételéhez.
• Lehetővé teszi, hogy bizonyos tesztek (akadálymentes-e ez a PDF?) esetében bizonyos szerepkörök webhelyszinten elutasíthassák a riasztásokat.
• Megosztott konfiguráció: külön szerepköralapú tesztelés és jelentésnézetek fejlesztőknek és tartalomszerzőknek.

És ami a projekt jövője szempontjából talán a legfontosabb:

• Támogatást nyertünk ennek a szponzoráló szervezetnek az elindításához, amely segíti a meglévő felhasználókat, és finanszírozza a jövőbeli projektötletek megvalósítását.

v2: Elutasítások & jelentések

2023. március 2.

Két évvel ezelőtt bemutattuk az Editoria11y akadálymentességi ellenőrzőt, egy kulcsrakész Drupal-webhelybővítményt, amely automatikus, azonnali visszajelzést ad a szerzőknek, és hasznos tippekkel segíti a tartalmuk javítását.

Úgy gondoltuk, ezzel egy kielégítetlen igényre válaszolunk. A meglévő megoldások mindegyike képzést és szorgalmas használatot igényelt ahhoz, hogy hasznos legyen, és a tapasztalat azt mutatta, hogy több ezer tartalomszerző képzése és felügyelete egy nagy szervezetben nem hatékony megoldás. Meggyőződésünk volt, hogy a program sikeréhez magas fokú automatizálásra van szükség: ha gyakori hibát észlel, udvarias, „épp időben érkező képzést” kell nyújtania a tartalomszerzőknek.

Bevált.

A Princetonon nagyrészt megfordította a kommunikációm irányát. Azokon a platformokon, ahol telepítve volt, az ismétlődő e-mailek küldözgetése helyett, amelyekben alt szövegek, linkek vagy címsorok javítását kértük a tartalomszerzőktől, immár mi kaptunk tőlük kérdéseket arról, hogyan javíthatnák az írásukat, hogy az eszköz ne jelölje meg ennyiszer.

A külvilág reakciója eufória volt:

Önálló tippek írása

A v1-es tippeknél „összefoglaló és részletek” megközelítést alkalmaztunk: a probléma rövid magyarázata, és egy link a részletekhez.

Ez előrelépés volt a fejlesztőknek írt eszközökhöz képest: a tippek rövidek és világosak voltak. Csakhogy mindig kérdéses volt, hová mutasson a link. Több kormányzati és felsőoktatási felhasználó úgy érezte, módosítania kell a tippeket, hogy eltávolítsa a Princeton dokumentációjára mutató linkeket, ami többletmunkát jelentett nekik. Ezért az alapértelmezett tippeket önállóra írtuk át, beépített példákkal.

A piros riasztások (egyértelmű problémák) és a sárga figyelmeztetések (lehetséges problémák) közötti különbség zavarónak, időnként pedig idegesítőnek bizonyult.

Ezért a sárga figyelmeztetéseket „manuális ellenőrzésekké” alakítottuk, hogy világosabb legyen a jelentésük, és gombokat adtunk hozzá, amelyekkel a szerzők elutasíthatják a riasztásokat. A „figyelmen kívül hagyott” riasztások csak annak a személynek rejtődnek el, aki rákattint; az „OK-nak jelölt” riasztások a webhely összes szerkesztője elől rejtve maradnak. A webhelyadminisztrátorok eldönthetik, kinek melyikre van jogosultsága.

Vezérlőpult létrehozása

A webhelytulajdonosok gyakori panasza volt, hogy az eszköz remekül megtalálja a problémákat a webhely egészén, de nincs mód webhelyszintű jelentés megtekintésére.

Az újraírás lehetőséget ad arra, hogy az eredmények visszaszinkronizálódjanak a webhely adatbázisába. A webhelytulajdonosok mostantól oldal vagy probléma szerint böngészhetik az eredményeket, áttekinthetik, mely problémákat hagytak figyelmen kívül vagy jelöltek OK-nak – és ha nem értenek egyet, visszaállíthatják a problémát!

V2 kódbemutató fejlesztőknek

A V2 szinte teljes újraírás volt. Néhány új funkció:

• A jQuery-függőség megszüntetése lehetővé teszi a telepítést több platformra, és kétszeres teljesítménynövekedést hoz.
• Az ellenőrző mostantól úgy állítható be, hogy az oldal több, egymástól független részében keressen (pl. a cikk tartalmában és az oldal láblécében).
• Az ellenőrző mostantól az árnyék-DOM-ban lévő elemeket is tudja tesztelni; ezt különféle webkomponensek és JavaScript-könyvtárak használják.
• Számos új paraméter könnyíti meg a platformintegrációkat, például bizonyos oldalakon bizonyos felhasználóknál minden probléma automatikus figyelmen kívül hagyása, ha nem ők felelnek az adott oldal tartalmáért, de igény szerint mégis megtekintenék az eredményeket.
• Az ellenőrző mostantól több alaptémával és a színek testreszabására szolgáló paraméterekkel érkezik.
• Az automatizált tesztelés segít megelőzni a kódregressziókat.

A11yTalks 2024

2024. június 11.

Drupal GovCon 2023

2023. október 27.

DrupalCamp NJ 2023

2023. március 28.

v1: Szövegközi súgó

2021. március 11.

A magas szinten akadálymentes webes tartalom létrehozása bonyolult, és általában rengeteg képzéssel kezdődik.

A megszokott gyakorlatokról le kell szoktatni az embereket:

• A táblázatokat nem szabad álhasábok létrehozására használni
• A folyó szöveget nem szabad középre igazítani vagy sorkizárni
• A tisztán vizuális formázásra (betűvastagság és -méret) nem szabad a jelentés közvetítését bízni, hiszen a felhasználók esetleg hallgatják a tartalmat, vagy „olvasó módban” nézik

Új gyakorlatokat kell meghonosítani:

• A képeknek a kontextusnak megfelelő, értelmes alternatív szövegre van szükségük
• Az oldalaknak valódi szerkezetre van szükségük
• A linkeknek értelmes címet kell adni

Természetesen egyes képzéseinket azért tartjuk, mert új fogalmakat tanítunk, de egy ponton fel kell tenni a kérdést: az új készségek iránti igény mekkora része fakad abból, hogy a fogalmak újak, és mekkora abból, hogy új elvárásokat vezetünk be anélkül, hogy frissítenénk az eszközeinket? Attól, hogy valami új, még lehet intuitív.

A helyesírás történetének tanulságai

1. fázis: A szerző a hibás

Az írott történelem hajnalától egészen az 1980-as évek elejéig a szerzőt hibáztattuk, ha elírt egy szót. A szerző felelőssége volt, hogy megtanuljon helyesen írni.

Hogyan fejleszthette valaki a helyesírását? Ismerős lesz:

1. Képzésekre jártak, magántanárhoz vagy osztályterembe
2. Listákat, útmutatókat és szótárakat kaptak tanulmányozásra – egészen az agyagba vésett ősi ékírásos szójegyzékekig visszamenőleg.

2. fázis: A szótár a hibás

Az 1980-as években azonban valami megváltozott: nevezzük ezt „a helyesírás 2. fázisának”. A legnépszerűbb szövegszerkesztő programok bevezették a helyesírás-ellenőrzést.

És mi történt a bűnbakkereséssel? Szinte egyik napról a másikra az eszközre hárult a felelősség:

• Nem tudja, hogyan kell leírni egy szót? Tippeljen, és reménykedjen, hogy talál egyezést. Ha nem, a szótár a hibás.
• Olyan létező szót használ, amelyet a szótár nem ismer, és ezért megjelöl? Morogjon egyet, majd döntse el, hogy figyelmen kívül hagyja az aláhúzást, vagy jobb gombbal kattintva felveszi a szót a szótárba.

Megjavította a helyesírás-ellenőrzés az összes helyesírásunkat? Dehogy. De segített. És a teher és a felelősség nagy részét a szerzőről a gépre hárította.

Ezzel azonban még nem volt vége…

3. fázis: A szerzői eszköz a hibás

Az elmúlt évek újabb előrelépést hoztak: a számítógépek elkezdtek helyettünk írni:

• A prediktív algoritmusok megpróbálják kitalálni a következő szót, a következő kifejezést, sőt akár egy teljes szöveges üzenetre adott választ is.
• Az automatikus formázó eszközök megpróbálják listává alakítani a csillagokat, számokat és betűket, a rövid kódokat pedig speciális karakterekké és emojikká stb.
• A diktálóeszközök megpróbálják felismerni a fogalmakat, hogy választani tudjanak az azonos hangzású szavak között.

És ki a hibás, ha mindez összeomlik? Az eszköz!

A közösségimédia-gyűjtőoldalak imádják a kínos „Nem ezt akartam írni!” képernyőképeket.

Az Editoria11y egy lépés a 2. fázis felé

Képzéseinken sokat beszélünk a tesztelésről, és több igazán jó tesztelőeszközt is bemutatunk. Egyikük sem képes mindent észrevenni: az olyan elveket, mint a „fogalmak magyarázatának elkerülése szín- vagy térbeli utalásokkal”, embernek kell ellenőriznie; az eszközök jellemzően a webhelyeken ténylegesen előforduló problémák valamivel kevesebb mint felét találják meg. A szerkesztői tartalomban előforduló gyakori hibák közül azonban sokat kiválóan kiszűrnek.

Csakhogy három probléma is van:

1. A legtöbbjük manuális eszköz. A tartalomkészítőt meg kell tanítani a használatukra, emlékeznie kell arra, hogy léteznek, amikor a tartalmat írja, és arra is, hogy a végén le kell futtatnia őket. Ez a három hibapont összefog, és így sok (a legtöbb?) tartalom ellenőrizetlen marad.
2. Túl sok mindent jelölnek meg. Nemcsak a szerző által épp elkövetett hibákat jelölik, hanem a tervező színproblémáit, a fejlesztő technikai hibáit, tájékoztató célú szerkezeti elemeket stb. Ez megemeli a képzés mércéjét: a szerzőknek nemcsak az eszközt kell megérteniük, hanem azt is meg kell tanulniuk, hogy figyelmen kívül hagyjanak egy sor téves riasztást vagy nagyon is valós dolgot, amelyek kijavítása ma, ennek a cikknek a megírása közben nem az ő felelősségük.
3. Az automatizált eszközök jellemzően a „feltérképezed a webhelyet, felkeresed a vezérlőpultot” modellt követik. Ismét: ez feltételezi, hogy a szerzőt megtanították felkeresni a vezérlőpultot, és nem is felejti el.

A Princeton ezért valami új létrehozására vállalkozott: egy webhelybe integrált, automatikus ellenőrzőre, amely csak a gyakori szerkesztői hibákat vizsgálja.

Automatikusnak lenni… nehéz.

1. Az automatikus ellenőrzőknek finomnak kell lenniük: ha túl rámenősek, megzavarják és frusztrálják a szerzőt. Ha túl udvariasak, könnyen figyelmen kívül hagyott háttérzajjá válhatnak.
2. Az automatikus ellenőrzőknek nagy teljesítményűnek kell lenniük: ha az oldal rázkódik vagy megakad futás közben, a szerzők megutálják és kikapcsolják őket.
3. Az automatikus ellenőrzőknek kezdőbarát tippekre van szükségük. Sok szerző itt hall először azokról a címkézési, szerkezeti és nyelvi megoldásokról, amelyek akadálymentesebbé teszik a tartalmukat. A riasztásoknak egyszerű, nem szakmai nyelven kell szólniuk, és gyakorlati tanácsokat kell adniuk a tartalom javításához.

Ezért a céljainkhoz legközelebb álló eszközből indultunk ki: a Toronto Metropolitan University-n készült Sa11y-ból. Átvettük a tesztarchitektúráját és a felhasználóbarát, eszköztippekkel kiegészített információs panel megközelítését, majd fél évig alakítottuk az eszközt: elértük, hogy a tesztek mindig automatikusan fussanak, optimalizáltuk a teljesítményét, finomítottuk az eszköztippeket, és létrehoztunk egy hosszú listát azokról a konfigurációs lehetőségekről, amelyekkel a fejlesztők gyorsan bármely platformhoz igazíthatják.

Így néz ki ma:

Amikor egy szerző bejelentkezik a webhelyére, az Editoria11y kapcsolója minden oldalon jelzi a problémák számát és típusát (megfelelt, manuális ellenőrzés szükséges, valószínű problémák). Rákattintva megjeleníthetők a szövegközi kiemelések és tippek. Ha a hiba új, mert a szerző egy épp most szerkesztett oldalt néz, a panel automatikusan megnyílik.

2021 márciusában ez azt jelenti, hogy több mint 400 princetoni webhely ellenőrzi automatikusan a következőket:

• Jó dokumentumvázlat
  • Kihagyott címsorszintek
  • Üres címsorok
  • Nagyon hosszú címsorok
  • Gyanúsan rövid blokkidézetek, amelyek valójában címsorok lehetnek.
• Szöveges alternatívák
  • Alt szöveg nélküli képek
  • Fájlnevet alt szövegként használó képek
  • Nagyon hosszú alt szöveggel rendelkező képek
  • Felesleges szavakat, például „kép erről” vagy „fotó erről” kifejezést tartalmazó alt szöveg
  • Linkekben lévő képek, amelyek alt szövege látszólag a képet írja le, nem a link célját
  • Beágyazott vizualizációk, amelyekhez általában szöveges alternatíva szükséges
• Értelmes hivatkozások
  • Szöveg nélküli linkek
  • Fájlnevet címként használó linkek
  • Kizárólag általános szöveggel címzett linkek: „kattintson ide”, „további információ”, „letöltés” stb.
  • Új ablakban megnyíló linkek külső link ikon nélkül
• Általános minőségbiztosítás
  • Annak ellenőrzése, hogy csillagok, számok és betűk helyett listaformázást használnak-e
  • NAGY MENNYISÉGŰ CSUPA NAGYBETŰS SZÖVEG
  • Fejléc nélküli táblázatok, valamint olyan táblázatok, amelyekben táblázatfejlécek (<th>) helyett dokumentumcímsorok („3. címsor”) szerepelnek
  • PDF-ekre és más dokumentumokra mutató linkek, emlékeztetve a felhasználót, hogy ellenőrizze a letöltés akadálymentességét, vagy biztosítson más, akadálymentes formátumot
  • Beágyazott videók, emlékeztetve a felhasználót a zárt feliratok hozzáadására
  • Beágyazott hangfelvételek, emlékeztetve a felhasználót, hogy biztosítson átiratot
  • Beágyazott közösségimédia-tartalmak, emlékeztetve a felhasználót, hogy adjon meg alt elemeket

A JavaScript-könyvtárat közzétettük a közösség számára, kulcsrakész Drupal-integrációt hoztunk létre, és megkezdtük a munkát egy kulcsrakész WordPress-integráción.

A 3. fázis felé: alapértelmezetten akadálymentes

Az Editoria11y sok szempontból átmeneti megoldás. A kiszűrt hibák többsége azért történt, mert új elvárásokat támasztottunk a tartalomszerzőkkel szemben („lássa el a tartalmát jó szerkezettel”), de olyan eszközöket adtunk nekik, amelyek az ellenkezőjére ösztönöztek.

A továbblépés útja az, hogy az akadálymentes tartalomkészítést egyszerűbbé és a lehető legautomatikusabbá tegyük. Hogy ez pontosan hogyan néz ki, még nem egyértelmű, de valószínűleg ilyesmiket foglal magában:

• Az elérhető lehetőségek újragondolása. Például: ha folyton azt mondjuk a felhasználóknak, hogy ne sorkizárjanak szöveget a weben, nem jött el az ideje, hogy nyugdíjazzuk a „Sorkizárás” gombot?
• Az alapértelmezett beállítások újragondolása. Például: a legtöbb tartalomkezelő rendszerben az alapértelmezett táblázatnak nincs fejléce. A felhasználón múlik, hogy tudja: a „Tulajdonságok” gombra kell kattintania, és hozzá kell adnia az akadálymentességi funkciókat; talán ideje ezt megfordítani?
• A prediktív formázás és a „munka közbeni utalások” átgondolása. Ha a felhasználó egy teljes sort félkövérré tesz, javasolhatjuk-e, hogy legyen belőle címsor? Ha címsort készül kiválasztani, ki tudjuk-e találni, milyen szintre lehet szüksége, ahelyett hogy hat lehetőséget kínálnánk fel? Tudunk-e épp időben érkező képzést nyújtani a nehéz fogalmakhoz?