9.4 – A szabványok mint közös iránymutatások – Standards als gemeinsame Leitplanken

1. Egy billentyűzetet használó személy eléri a bejelentkezési mezőt, de egy rögzített sáv eltakarja azt, amikor a fókusz oda kerül, így az oldal fogadja a billentyűleütéseket anélkül, hogy megmutatná, melyik vezérlőelem fogja azokat fogadni .

2. A mezőnek van fókusza; a pozíciója azonban eltűnt .

3. A továbblépéshez találgatásra van szükség, és a következő képernyő megkövetelheti a memóriából felidézett jelszót vagy egy rejtvény megoldását, mielőtt hozzáférést biztosítana, még akkor is, ha maga a szolgáltatás tökéletesen használható lehet, miután valaki bejutott .

4. A képernyő hipotetikus, az akadályok viszont nem .

5. Ezek azok a fajta akadályok, amelyeket egy nyilvános webes szabvány a homályos panaszokból olyan kérdésekké alakíthat, amelyeket a tervező és az értékelő együtt vizsgálhatnak meg .

6. A megkülönböztetés már azelőtt fontos, hogy bárki is leírna egy sor kódot .

7. Egy fejlesztő láthat egy működő bejelentkezési gombot, míg egy billentyűzetet használó felhasználó nem tudja megmondani, hol várja az oldal a következő műveletet, mert a billentyűzetfókusz vizuális jelölője eltűnt a webhely által oda elhelyezett tartalom mögött .

8. Egy megrendelő kérhet „akadálymentes bejelentkezést” anélkül, hogy meghatározná, mit is jelent ez a kifejezés, így a kivitelezőre marad a döntés, hogy egy rejtett, fókuszált mező hibának számít-e, vagy csupán egy kellemetlen apróságnak .

9. Két kivitelező így eltérő eredményeket szállíthat le, és mindkettő sikerről beszélhet.

10. A közös kritériumok szűkítik a félreértések lehetőségét .

11. 2023 októberében a World Wide Web Consortium (W3C) ajánlásként tette közzé a Webtartalom-akadálymentességi irányelvek 2.2-es verzióját.

12. Az egyik új kritérium, az úgynevezett „A fókusz nem takarható el (minimum)”, a rejtett mezővel foglalkozik.

13. AA szintjén kimondja, hogy a billentyűzetfókuszt kapó komponens nem takarható el teljesen az oldal szerzője által létrehozott tartalom által – ez egy olyan feltétel, amelyet az értékelő az oldalra alkalmazhat, nem pedig a fejlesztő szándékaira .

14. A „teljesen” szó valódi jelentőséget hordoz.

15. Ez a minimum nem garantálja, hogy a mező minden része látható marad; a teljes láthatóságot egy szigorúbb, különálló AAA-kritérium szabályozza, így a minimumot a mező akadálymentességének garanciájaként emlegetni túlzás lenne .

16. Ezenkívül megkülönbözteti a szerző által létrehozott akadályokat azoktól a tartalmakól, amelyeket a felhasználó elmozdíthat vagy láthatóvá tehet.

17. A tesztelőnek tehát egy meghatározott kérdést kell feltennie, nem pedig általános benyomásról kell beszámolnia .

18. A másik akadály akkor jelentkezik, amikor a bejelentkezés kognitív feladatot igényel, különösen akkor, ha a felhasználónak ezt alternatív módszer vagy a terhet csökkentő eszköz nélkül kell elvégeznie .

19. A WCAG 2.2 „Akadálymentes hitelesítés (minimum)” kritériuma kimondja, hogy ilyen feladat nem követelhető meg, kivéve, ha a lépés több meghatározott kerülőút vagy átjutási lehetőség egyikét kínálja .

20. A jelszó megjegyzése egy példa a kognitív feladatokra, és ha a felhasználótól megkövetelik, hogy leírjon egy kódot vagy megoldjon egy rejtvényt, az hasonló akadályt jelenthet a hitelesítés során .

21. A kritérium nem tiltja a jelszavakat.

22. A jelszókezelő támogatása vagy a jelszó beillesztésének lehetősége olyan segítséget nyújthat, amely kiküszöböli a memóriára vagy a leírásra való támaszkodás szükségességét.

23. Egy alternatív hitelesítési módszer is kielégítheti a feltételt, feltéve, hogy a felhasználó ténylegesen választhatja ezt az utat, ahelyett, hogy egy másik gomb mögött ugyanazzal a memóriateszttel szembesüljön .

24. A szabvány még bizonyos felismerési feladatokat is megenged, ami fontos korlátozás, amikor valaki a kritériumot a bejelentkezési rejtvények általános tiltásaként írja le.

25. Itt is az AA szint a mérvadó.

26. A közös cél a folyamat elérése, nem pedig egy előírt képernyőterv, ami azt jelenti, hogy a csapatok különböző módokon oldhatják meg az akadályt, miközben egy érthető, közös eredményre kell törekedniük.

27. Az egyik csapat a görgetési viselkedés megváltoztatásával megakadályozhatja, hogy egy rögzített fejléc eltakarja a fókuszált vezérlőelemeket, míg egy másik csapat megváltoztathatja az átfedést okozó elrendezést .

28. A teszt arra az eredményre vonatkozik, amikor a fókusz elmozdul.

29. Hasonlóképpen, egy webhely támogathat jelszókezelőket vagy biztosíthat más hitelesítési módot, feltéve, hogy a meghatározott feltétel a folyamat egészében teljesül, és nem tűnik el egy későbbi ellenőrzési lépésben .

30. Ez teret hagy a technikai innovációnak egy nyilvános kereteken belül .

31. E keret nélkül minden vásárlónak újra kellene tárgyalnia a hozzáférés jelentését, és minden értékelőnek meg kellene védenie saját értelmezését, miután probléma merül fel, amikor a szerződés vagy az interfész módosítása már nehezebb .

32. Egy szabvány ezeket a tárgyalásokat egy átadható hivatkozásba sűríti .

33. Értéke akkor látható, amikor egy szerződés, egy tervezési brief és egy átvételi teszt ugyanarra a számozott követelményre hivatkozhat, így a beszállító tudja, mit kell elkészítenie, a vásárló pedig meg tudja magyarázni, miért nem felel meg az eredmény .

34. Ezek a számok helyet adnak a nézeteltérésnek .

35. A felek továbbra is vitathatják, hogy egy adott oldal megfelel-e, különösen akkor, ha a kivétel a felhasználói viselkedéstől függ, de nem kell azzal kezdeniük, hogy kitalálják a vitatott kérdést .

36. A felhasználók számára ez a közös nyelv azt is lehetővé teszi, hogy a hibát egy adott böngésző-munkameneten túl is leírhassák .

37. A kritériumok nem egy kész csomagban jelentek meg.

38. A WCAG 2.0 2008-ban vált W3C-ajánlássá, ezt 2018-ban a WCAG 2.1 követte, majd 2023-ban a WCAG 2.2 folytatta ezt a sorozatot .

39. Minden verzió stabil, hivatkozható szöveget biztosít, míg a W3C egyben linket is fenntart a legfrissebben közzétett verzióhoz, lehetővé téve az értékelő számára, hogy megkülönböztesse a szerződésben megnevezett követelményeket a később megjelent iránymutatásoktól.

40. A két hivatkozás közötti különbség gyakorlati jellegű.

41. A dátummal ellátott verzió lehetővé teszi a szerződés számára, hogy pontosan meghatározza az elfogadáshoz használt követelményeket, míg a legfrissebb verzióra mutató link segít a tervezőknek megtalálni az aktuális iránymutatásokat.

42. A stabilitás lehetővé teszi az összehasonlítást; a felülvizsgálat pedig a javítást.

43. A W3C Akadálymentességi Irányelvek Munkacsoportja a szöveget olyan folyamat keretében dolgozza ki, amely nyilvános észrevételeket kér és rögzíti a lényegi kérdésekre adott válaszokat, így a szövegezőcsoporton kívüli személyeknek is lehetőségük nyílik a javasolt megfogalmazás és annak hatásai megkérdőjelezésére .

44. A folyamat lehetőséget biztosít formális kifogások benyújtására is, amennyiben a nézeteltérés a szokásos megbeszélés során sem oldódik meg .

45. A kifogásnak indoklással kell rendelkeznie, és azt hivatalosan meg kell vizsgálni, de a nyílt folyamat nem jelenti azt, hogy minden javasolt kritérium bekerül a végleges dokumentumba .

46. A munkacsoportnak a követelményeket elég egyértelműen kell megfogalmaznia ahhoz, hogy tesztelhetők legyenek, és elég széles körűen ahhoz, hogy különböző technológiákra alkalmazhatók legyenek, mivel egy adott webes eszközhöz túl szorosan kötődő szabvány kevésbé hasznos lehet, ha az eszköz megváltozik.

47. Ezek a követelmények ellentétes irányba is hatnak.

48. Egy szűken meghatározott javítás könnyen ellenőrizhető lehet, de egy új felületen kudarcot vallhat, míg egy tágabb célkitűzés egyetértést válthat ki, és mégis előfordulhat, hogy két értékelő nem jut ugyanarra az ítéletre.

49. A WCAG az általános célokat a tesztelhető állításokként megfogalmazott sikerkritériumok mellé helyezi .

50. A kiegészítő magyarázatok és technikák ezután bemutatják a célok elérésének lehetséges módjait anélkül, hogy minden példát az egyetlen megengedett tervezési megoldássá tennének, vagy egy tanácsadó technikát olyan követelménnyé alakítanának, amelyet maga az ajánlás soha nem írt elő .

51. Ez a felosztás bizonyos mértékű ellenállóképességet biztosít a szabványnak a webes technológia változásai esetén .

52. Emellett megmutatja a szervezeteknek, hová kell fordulniuk, ha egy felhasználó olyan akadályt jelent be, amelyet a jelenlegi kritériumok nem írnak le megfelelően.

53. A munka sem tisztán technikai, sem tisztán politikai jellegű .

54. Az, hogy mit lehet tesztelni, meghatározza, mely nehézségeket könnyű pontosan megfogalmazni a beszerzés, a végrehajtás és a nyilvános viták során, míg azok az igények, amelyek nem alkalmasak közös tesztelésre, továbbra is nehezebben alakíthatók át szerződéses kötelezettséggé .

55. A fogyatékossággal élő emberek és az akadálymentességi szakértők észrevételeiken keresztül vitathatják ezt a választást, de a végleges szöveg továbbra is a bizonyítékokkal és a megvalósíthatósággal kapcsolatos megítéléseket tükrözi .

56. A véleménynyilvánításra való felhívás nem tudja kiküszöbölni az időbeli, szakértelmi vagy a szövegezési folyamatba való hozzáférés terén fennálló egyenlőtlenségeket, ezért a közzétett szöveget továbbra is alaposan át kell vizsgálni azoknak az embereknek, akiknek az igényei nem kerültek be a sikerkritériumok közé .

57. Ez viszont nyitottabbá teszi az érvelést a vitára .

58. A bejelentkezési képernyő így egy intézményi kérdést vet fel: mely nyilvános szöveg betartását ígéri meg egy szervezet, és hogyan fog tudomást szerezni azokról az akadályokról, amelyeket a szöveg nem vesz figyelembe?

59. Ez a kérdés még élesebbé válik, amikor egy szabvány jogi szabályként lép életbe .

60. A W3C ajánlást tesz közzé széles körű önkéntes alkalmazás céljából; nem tanúsítja az egyes webhelyeket, és nem teszi minden új verziót törvényerővé, mivel a kötelező érvény a kormány vagy egy másik elfogadó szerv külön döntésétől függ .

61. Az Egyesült Államokban a felülvizsgált 508. szakasz szabványai konkrét példát nyújtanak a hatóságok általi elfogadásra .

62. Az amerikai Access Board 2017-es szabálya beépíti a WCAG 2.0 A és AA szintű teljesítési kritériumait és megfelelési követelményeit a szabályozás hatálya alá tartozó elektronikus tartalmakra vonatkozóan, meghatározva azt a szöveget, amelyhez képest a jogi kötelezettséget értékelik .

63. A szövetségi ügynökségeknek 2018 januárjától kellett megfelelniük a felülvizsgált 508. szakasz követelményeinek, a szabály rendelkezéseinek és kivételeinek figyelembevételével, és a szabály nem kezelte a W3C jövőbeli kiadványait automatikus módosításként .

64. A hivatkozás egy verziót nevez meg.

65. Nem lép át automatikusan a 2.0-ról a 2.1-re vagy a 2.2-re, valahányszor a W3C újabb ajánlást tesz közzé.

66. Egy szövetségi beszerző ezért nem feltételezheti, hogy minden új WCAG 2.2 kritérium máris a 508. szakasz szerinti kötelezettség, még akkor sem, ha a kritérium valódi akadályt azonosít azok számára, akik a beszerzett szolgáltatást igyekeznek használni .

67. A beszerző továbbra is többet kérhet a szerződésben, és a tervezőcsapat önként alkalmazhatja az újabb iránymutatásokat.

68. A jogi kötelezettség és a tervezési törekvés külön mondatokban kell, hogy szerepeljenek .

69. Ez a megkülönböztetés mind az elszámoltathatóságot, mind az egyértelműséget védi: a hatóság meghatározhatja, mit ír elő a szabály, miközben elmagyarázza, miért javítaná egy későbbi kritérium az akadálymentességet, ahelyett, hogy saját beszerzési döntését egy régebbi verziót megnevező törvényre hivatkozna.

70. Ez megakadályozza azt is, hogy a beszállító a régebbi jogi alapot ürügyként használja fel egy újonnan látható akadály figyelmen kívül hagyására.

71. A rögzített sáv kézzelfoghatóvá teszi a különbséget.

72. Egy billentyűzetet használó felhasználó találkozhat egy teljesen elrejtett, fókuszált vezérlőelemmel – pontosan ez a probléma, amelyet az új WCAG 2.2 AA kritérium kezel –, függetlenül attól, hogy az oldal készítője teljesítette-e egy korábbi ellenőrzőlistát .

73. Az a értékelő, aki kizárólag a beépített WCAG 2.0 szöveget alkalmazza, nem nevezheti át azt a kritériumot automatikus 508. szakasz szerinti követelménynek.

74. Az a szervezet, amely a WCAG 2.2-t választja saját elfogadási tesztjéhez, közvetlenül megkérdezheti, hogy a vezérlőelem legalább részben látható-e .

75. Mindkét állítás egyszerre igaz lehet.

76. A szabályban megnevezett verzió határozza meg a jogi tesztet; a későbbi verzió feltárhat egy olyan problémát, amelyet érdemes kijavítani .

77. A verziók más irányban is eltérhetnek egymástól.

78. A WCAG 2.2 eltávolította a régebbi 4.1.1. sikerkritériumot („Elemzés”), miután a W3C arra a következtetésre jutott, hogy eredeti célja elavulttá vált, mivel a segítő technológiáknak már nem kellett közvetlenül elemezniük a HTML-t .

79. A W3C szerint az ilyen jellegű fennmaradó problémák vagy megszűntek, vagy más kritériumok kezelik őket, bár a fejlesztőknek továbbra is gondoskodniuk kell arról, hogy a vezérlőelemek a segítő technológiákkal is működjenek .

80. A javítás lehet hozzáadás is, és kivonás is.

81. Az eltávolítás azt mutatja, hogy egy teszt elveszítheti célját anélkül, hogy a használható, kompatibilis kód alapvető célja kevésbé fontos lenne.

82. Ugyanakkor egy régebbi irányelv még mindig utalhat egy olyan verzióra, amely tartalmazza azt a kritériumot, és az irányelvhez kötött csapatnak külön kell vizsgálnia a régebbi hivatkozást, ahelyett, hogy feltételezné, hogy a törlés visszamenőlegesen is érvényes.

83. Aki a WCAG 2.2-nek való megfelelést jelenti, annak ezért szükség lehet egy külön ellenőrzésre a 4.1.1-es kritérium tekintetében, ha egy alkalmazandó irányelv még mindig a WCAG 2.0-ra vagy 2.1-re hivatkozik.

84. Egyetlen címke, például a „WCAG-kompatibilis”, túl sokat rejthet magában.

85. Meg kell határoznia a verziót és a szintet, és nem szabad azt sugallnia, hogy egy későbbi verzió átírta a korábbi szabályt.

86. A W3C a 2.x sorozatot úgy tervezte, hogy az elsősorban kiegészítésekkel épüljön fel, így a korábbi munka nagy része továbböröklődik, és az újabb verziót átvevő csapatnak nem kell minden korábbi követelményt a nulláról újra megtanulnia.

87. A 4.1.1 pont eltávolítása jól mutatja, miért fontos a „elsősorban” kifejezés.

88. A stabil hivatkozások és a frissített iránymutatások különböző problémákat oldanak meg, és egyik sem helyettesítheti egyszerűen a másikat.

89. Ha egy jogi hivatkozás automatikusan megváltozna, a közjogi kötelezettségek a szabványalkotási folyamat során eltolódhatnának anélkül, hogy az azt átvevő hatóság tudatosan döntene erről, ezért érdemes odafigyelni a szabályban szereplő verziószámra.

90. Ha soha nem változna, az átvett szöveg elveszítheti a kapcsolatot az újabb eszközök, gyakorlatok és kutatások által feltárt nehézségekkel, így a hatóságok egy elavult minimumot kénytelenek betartani, miközben a felhasználók olyan akadályokkal szembesülnek, amelyeket az újabb szabvány megnevezhetne.

91. A felelős intézménynek el kell döntenie, mikor vizsgálja felül a hivatkozást, milyen bizonyíték indokolja a módosítást, és hogyan tudhatják meg a szabályozott felek, hogy melyik verzió alkalmazandó, mert egy hiperhivatkozás csendes megváltoztatása nem képes ellátni ezt a szabályozó feladatot .

92. Ez egy adminisztratív döntés, amelynek következményei a bejelentkezési képernyőn is érezhetők .

93. Egy kormányzati szerv megtarthatja a jogi hivatkozás pontos szövegét, miközben a vállalkozóknak egy adott projektre vonatkozóan egyértelműbb, ambiciózusabb célt tűzhet ki.

94. Emellett el kell kerülnie azt az ígéretet, hogy egy ellenőrzőlista önmagában minden felhasználói élményt rendezni fog .

95. A WCAG kifejezetten kimondja, hogy még a legmagasabb megfelelési szint sem fedi le a fogyatékosságok minden típusát, fokát vagy kombinációját, különösen akkor, ha a kognitív, nyelvi és tanulási igények meghaladják azt, amit a kritériumok le tudnak fedni.

96. A szabvány tesztelhetősége egy olyan erősség, amelynek vannak határai .

97. Egy kritériumnak elég általánosnak kell lennie ahhoz, hogy webhelyeken átívelően alkalmazható legyen, és elég pontosnak ahhoz, hogy különböző értékelők is elbírálhassák, ami miatt egyes igények kívül maradnak a formális hatályán .

98. A probléma különösen élesen jelentkezik, ha egy nehézség az egyén kontextusától, a környező feladattól vagy több kisebb, együttesen ható akadálytól függ.

99. Előfordulhat, hogy egy oldal minden felsorolt kritériumnak megfelel, és mégis nehezen használható .

100. Ezzel szemben egy nem teljesített kritérium valódi hibát jelez, még akkor is, ha egyes felhasználóknak sikerül megkerülniük azt .

101. Egyik megfigyelés sem teszi feleslegessé a tesztelést.

102. A tesztek olyan minimumszintet határoznak meg, amelyet a vásárló megadhat, és az értékelő ellenőrizhet, míg az érintett felhasználókkal végzett megfigyelés feltárhatja, mit hagy ki ez a minimumszint, amikor a felhasználók egy tényleges feladatot próbálnak elvégezni az elejétől a végéig.

103. Az automatizált eszközök segítenek bizonyos hibák felkutatásában, de a WCAG az emberi értékelést tekinti a megfelelőség megállapításának részének .

104. Ha figyeljük, ahogy az emberek végigcsinálják a tényleges bejelentkezési folyamatot, egy további kérdés merül fel: el tudják-e érni a szolgáltatást elkerülhető erőfeszítés vagy zavar nélkül?

105. Ez a gyakorlati vizsgálat inkább a lapok közötti sorrendben rejlő problémát tárhat fel, mint egy elszigetelt vezérlőelemet.

106. Felfedheti továbbá a biztonsági óvintézkedések és az akadálymentes hitelesítés közötti ütközést is, amelyet a projektcsapatnak meg kell oldania, ahelyett, hogy csupán felsorolná.

107. Nincs garancia arra, hogy egy felhasználói tesztelési kör mindenki számára reprezentatív legyen.

108. A résztvevők toborzása, a kiválasztott feladat, a használt eszközök és az eredmények értelmezésének módja mind-mind alakítják azt, amit a csapat megtanul, így egy sikeres résztvevő nem helyettesítheti mindazokat, akik később használni fogják a szolgáltatást.

109. A visszajelzések azonban jelzik a megrendelőnek, hogy egy formálisan megfelelő felület hol nem felel meg az elvárásoknak, és bizonyítékul szolgálhatnak a jövőbeli szabványalkotási munkához, ha az eredményeket dokumentálják, ahelyett, hogy a megfelelés kivételeiként elvetnék őket.

110. Fontos az út vissza a szabványhoz .

111. A nyilvános észrevételek új megfogalmazásokat javasolhatnak, a munkacsoportok pedig tesztelhetik, hogy azok egyértelműek és megvalósíthatók-e, a korábbi verziók pedig megőrizhetik a régebbi kifejezéseket azok számára, akikre azok még mindig vonatkoznak.

112. Egy szervezet eközben dokumentálhat további követelményeket egy beszerzéshez anélkül, hogy úgy tenné, mintha azok már a beépített szabály részét képeznék, megőrizve ezzel mind a jobb hozzáférés iránti igény szabadságát, mind a jogi beszámoló pontosságát.

113. Az alternatíva egy jól ismert zavar: egy jogi jelölőnégyzetet a teljes hozzáférés bizonyítékaként kezelnek, vagy minden felülvizsgálatot úgy kezelnek, mintha az azonnal megváltoztatná a jogi kötelezettségeket.

114. Mindkét zavar elrejti a felelősséget.

115. A szabályt megfogalmazó személy választja ki a hivatkozást; a beszerző választja ki a projekt célját; a fejlesztő választja ki a megvalósítást; az értékelő pedig egy azonosított szöveg alapján ítéli meg azt.

116. Azoknak a felhasználóknak, akik még mindig akadályba ütköznek, szükségük van egy csatornára, hogy ezt bejelenthessék, még akkor is, ha a teszt sikeres volt, mert az akadálymentességi szabvány célja a szolgáltatáshoz való hozzáférés, nem pedig egy kész táblázat .

117. Minden szerepkörnek másfajta hatásköre van, és a közös szabvány csak akkor működik, ha ezek a hatóságok láthatják és megválaszolhatják egymás bizonyítékait.

118. A bejelentkezési mezőnél a fókusz továbbra is a rögzített szalagcím mögé csúszik.

119. A döntő intézményi eredmény nem az adott képernyő univerzális kialakítása, hanem egy olyan nyilvános mondat, amely elég pontos ahhoz, hogy feltárja az akadályt, és elég stabil ahhoz, hogy hivatkozni lehessen rá.

120. Ugyanilyen fontos döntés, hogy a hozzáférést szabályozó személyek a web változásai során is napirenden tartják-e ezt a mondatot, annak jogi hivatkozását és a bejelentkezni próbálók tapasztalatait.

1. Eine Person, die eine Tastatur benutzt, gelangt zu einem Anmeldefeld, doch ein feststehendes Banner verdeckt es, sobald der Fokus dorthin wechselt, sodass die Seite Tastenanschläge akzeptiert, ohne anzuzeigen, welches Steuerelement diese empfangen wird.

2. Das Feld hat den Fokus; seine Position ist verschwunden.

3. Um fortzufahren, ist Raten erforderlich, und der nächste Bildschirm verlangt möglicherweise ein aus dem Gedächtnis abgerufenes Passwort oder das Lösen eines Rätsels, bevor der Zugriff gewährt wird – auch wenn der Dienst selbst möglicherweise einwandfrei nutzbar ist, sobald man einmal Zugang hat.

4. Der Bildschirm ist hypothetisch; die Hindernisse sind es nicht .

5. Dies sind die Arten von Barrieren, die ein öffentlicher Webstandard von vagen Beschwerden in Fragen verwandeln kann, die ein Designer und ein Prüfer gemeinsam untersuchen können .

6. Diese Unterscheidung ist wichtig, noch bevor jemand auch nur eine Zeile Code schreibt.

7. Ein Entwickler sieht vielleicht eine funktionierende Anmeldeschaltfläche, während ein Tastaturbenutzer nicht erkennen kann, wo die Seite die nächste Aktion erwartet, da die visuelle Markierung des Tastaturfokus hinter Inhalten verschwunden ist, die von der Website dort platziert wurden .

8. Ein Auftraggeber könnte eine „barrierefreie Anmeldung“ verlangen, ohne zu spezifizieren, was dieser Begriff erfordert, sodass es dem Auftragnehmer überlassen bleibt, zu entscheiden, ob ein verstecktes Feld mit Fokus als Fehler oder lediglich als unpraktisches Detail gilt .

9. Zwei Auftragnehmer könnten dann unterschiedliche Ergebnisse liefern und beide behaupten, erfolgreich gewesen zu sein.

10. Gemeinsame Kriterien verringern diesen Spielraum für Missverständnisse .

11. Im Oktober 2023 veröffentlichte das World Wide Web Consortium (W3C) die „Web Content Accessibility Guidelines 2.2“ als Empfehlung.

12. Ein neues Kriterium namens „Focus Not Obscured (Minimum)“ befasst sich mit dem verborgenen Feld.

13. Auf der Stufe AA besagt es, dass eine Komponente, die den Tastaturfokus erhält, nicht vollständig durch vom Seitenautor erstellten Inhalt verdeckt werden darf – eine Bedingung, die ein Prüfer auf die Seite anwenden kann und nicht auf die Absichten eines Entwicklers .

14. Das Wort „vollständig“ spielt dabei eine entscheidende Rolle.

15. Diese Mindestanforderung verspricht nicht, dass jeder Teil des Feldes sichtbar bleibt; ein strengeres, separates AAA-Kriterium befasst sich mit der vollständigen Sichtbarkeit, sodass es eine Übertreibung wäre, die Mindestanforderung als Garantie für ein unversperrtes Feld zu bezeichnen .

16. Außerdem unterscheidet es vom Autor geschaffene Sichtbehinderungen von bestimmten Inhalten, die ein Nutzer verschieben oder sichtbar machen kann.

17. Ein Tester hat daher eine definierte Frage zu stellen, anstatt einen allgemeinen Eindruck zu schildern .

18. Die andere Barriere tritt auf, wenn eine Anmeldung eine kognitive Aufgabe erfordert, insbesondere wenn der Nutzer diese ohne eine alternative Methode oder ein Hilfsmittel, das die Belastung verringert, bewältigen muss .

19. Das Kriterium „Barrierefreie Authentifizierung (Mindestanforderung)“ der WCAG 2.2 besagt, dass eine solche Aufgabe nicht verlangt werden darf, es sei denn, der Schritt bietet einen von mehreren festgelegten Umgehungs- oder Durchführungswegen an.

20. Das Merken eines Passworts ist ein Beispiel für eine kognitive Aufgabe, und die Aufforderung an einen Nutzer, einen Code abzutippen oder ein Rätsel zu lösen, kann während der Authentifizierung ein ähnliches Hindernis darstellen.

21. Das Kriterium verbietet Passwörter nicht.

22. Die Unterstützung eines Passwort-Managers oder die Möglichkeit, ein Passwort einzufügen, kann eine Hilfe darstellen, die es überflüssig macht, sich auf das Gedächtnis oder das Abschreiben zu verlassen.

23. Eine alternative Authentifizierungsmethode kann die Bedingung ebenfalls erfüllen, vorausgesetzt, der Nutzer kann diesen Weg tatsächlich einschlagen, anstatt hinter einer anderen Schaltfläche vor derselben Gedächtnisprüfung zu stehen .

24. Der Standard lässt sogar bestimmte Erkennungsaufgaben zu – eine Einschränkung, die von Bedeutung ist, wenn jemand das Kriterium als generelles Verbot von Anmelderätseln beschreibt.

25. Auch hier gilt die Stufe AA .

26. Das gemeinsame Ziel ist der Zugriff auf den Prozess, nicht ein vorgeschriebenes Bildschirmdesign, was bedeutet, dass Teams die Barriere auf unterschiedliche Weise beseitigen können, während sie an ein verständliches, gemeinsames Ergebnis gebunden sind.

27. Ein Team kann beispielsweise verhindern, dass eine feste Kopfzeile die fokussierten Steuerelemente überdeckt, indem es das Scrollverhalten ändert, während ein anderes das Layout ändert, das die Überlappung verursacht .

28. Der Test bezieht sich auf das Ergebnis, wenn sich der Fokus verschiebt.

29. Ebenso kann eine Website Passwortmanager unterstützen oder eine andere Art der Authentifizierung anbieten, vorausgesetzt, die festgelegte Bedingung wird während des gesamten Prozesses erfüllt und verschwindet nicht in einem späteren Verifizierungsschritt .

30. Das lässt Raum für technische Innovationen innerhalb einer öffentlichen Grenze.

31. Ohne diese Grenze müsste jeder Käufer die Bedeutung des Zugriffs neu aushandeln, und jeder Bewerter müsste eine private Interpretation verteidigen, nachdem ein Problem aufgetreten ist – zu einem Zeitpunkt, an dem eine Änderung des Vertrags oder der Benutzeroberfläche schwieriger ist .

32. Ein Standard fasst diese Verhandlungen zu einer Referenz zusammen, die übertragbar ist.

33. Sein Wert wird sichtbar, wenn ein Vertrag, ein Lastenheft und ein Abnahmetest auf dieselbe nummerierte Anforderung verweisen können, sodass ein Lieferant weiß, was er zu erstellen hat, und ein Käufer erklären kann, warum ein Ergebnis den Anforderungen nicht entspricht .

34. Diese Nummern geben einer Meinungsverschiedenheit einen Bezugspunkt.

35. Die Parteien können weiterhin darüber streiten, ob eine bestimmte Seite den Anforderungen entspricht, insbesondere wenn eine Ausnahme vom Nutzerverhalten abhängt, aber sie müssen nicht damit beginnen, die strittige Frage erst zu erfinden .

36. Für Nutzer macht diese gemeinsame Sprache einen Fehler zudem über eine einzelne Browsersitzung hinaus beschreibbar .

37. Die Kriterien entstanden nicht in einem einzigen, fertigen Paket.

38. WCAG 2.0 wurde 2008 zur W3C-Empfehlung, WCAG 2.1 folgte 2018 und WCAG 2.2 setzte diese Reihe 2023 fort .

39. Jede Version liefert einen stabilen, zitierfähigen Text, während das W3C zudem einen Link zur zuletzt veröffentlichten Version bereitstellt, sodass ein Prüfer die in einem Vertrag genannten Anforderungen von später erschienenen Leitlinien unterscheiden kann .

40. Der Unterschied zwischen diesen beiden Ansätzen ist praktischer Natur.

41. Eine datierte Version ermöglicht es, in einem Vertrag die genauen Anforderungen für die Abnahme festzulegen, während der Link zur neuesten Version Entwicklern hilft, die aktuellen Leitlinien zu finden.

42. Stabilität ermöglicht Vergleiche; Überarbeitungen ermöglichen Korrekturen.

43. Die Arbeitsgruppe „Barrierefreiheitsrichtlinien“ des W3C entwickelt den Text in einem Prozess, der öffentliche Kommentare einholt und Antworten auf inhaltliche Fragen protokolliert, wodurch Personen außerhalb der Redaktionsgruppe die Möglichkeit erhalten, vorgeschlagene Formulierungen und deren Auswirkungen zu hinterfragen .

44. Der Prozess sieht auch formelle Einwände vor, wenn eine Meinungsverschiedenheit über die normale Diskussion hinausbesteht .

45. Ein Einwand muss begründet sein und wird formell geprüft, doch ein offener Prozess bedeutet nicht, dass jedes vorgeschlagene Kriterium in das endgültige Dokument aufgenommen wird .

46. Die Gruppe muss Anforderungen so klar formulieren, dass sie überprüfbar sind, und so weit fassen, dass sie technologieübergreifend anwendbar sind, da ein Standard, der zu eng an ein bestimmtes Web-Tool gebunden ist, an Nützlichkeit verlieren kann, wenn sich dieses Tool ändert.

47. Diese Anforderungen können in unterschiedliche Richtungen weisen.

48. Eine eng gefasste Korrektur mag leicht zu überprüfen sein, versagt jedoch möglicherweise bei einer neuen Benutzeroberfläche, während ein weit gefasster Anspruch zwar Einigkeit hervorrufen mag, aber dennoch dazu führen kann, dass zwei Prüfer nicht zu demselben Urteil gelangen.

49. Die WCAG stellt allgemeine Ziele neben Erfolgskriterien, die als überprüfbare Aussagen formuliert sind .

50. Begleitende Erläuterungen und Techniken zeigen dann mögliche Wege auf, diese zu erfüllen, ohne jedes Beispiel zum einzig zulässigen Design zu machen oder eine empfohlene Technik in eine Anforderung zu verwandeln, die die Empfehlung selbst nie auferlegt hat .

51. Diese Aufteilung verleiht dem Standard eine gewisse Beständigkeit, wenn sich die Webtechnologie ändert.

52. Sie zeigt einer Organisation auch, wo sie nachsehen muss, wenn ein Nutzer eine Barriere meldet, die durch die aktuellen Kriterien nur unzureichend beschrieben wird.

53. Die Arbeit ist weder rein technisch noch rein politisch .

54. Die Entscheidung darüber, was getestet werden kann, bestimmt, welche Schwierigkeiten bei der Beschaffung, Durchsetzung und öffentlichen Debatte leicht zu spezifizieren sind, während Bedürfnisse, die sich einem einheitlichen Test entziehen, möglicherweise schwieriger in eine vertragliche Verpflichtung umzusetzen sind .

55. Menschen mit Behinderungen und Barrierefreiheitsspezialisten können diese Entscheidung durch Kommentare anfechten, doch der endgültige Wortlaut spiegelt dennoch Einschätzungen hinsichtlich der Evidenz und Umsetzbarkeit wider .

56. Eine Aufforderung zur Stellungnahme kann ungleiche Voraussetzungen hinsichtlich Zeit, Fachwissen oder Zugang zum Entwurfsprozess nicht ausgleichen, sodass der veröffentlichte Text weiterhin einer Prüfung durch Personen bedarf, deren Bedürfnisse nicht zu nummerierten Erfolgskriterien geworden sind.

57. Sie macht die Argumentation jedoch anfälliger für Kritik.

58. Der Anmeldebildschirm führt somit zu einer institutionellen Frage: Welchen öffentlichen Text wird eine Organisation einhalten, und wie wird sie von Barrieren erfahren, die der Text übersieht?

59. Diese Frage wird noch dringlicher, wenn ein Standard in eine gesetzliche Vorschrift einfließt .

60. Das W3C veröffentlicht eine Empfehlung zur breiten freiwilligen Anwendung; es zertifiziert keine einzelnen Websites und macht nicht jede neue Version zum Gesetz, da die Rechtsverbindlichkeit von einer gesonderten Entscheidung einer Regierung oder einer anderen übernehmenden Stelle abhängt .

61. In den Vereinigten Staaten bieten die überarbeiteten Section-508-Standards ein konkretes Beispiel für die Übernahme durch eine Behörde.

62. Die Verordnung des US-amerikanischen Access Board aus dem Jahr 2017 übernimmt die Erfolgskriterien und Konformitätsanforderungen der WCAG 2.0 der Stufen A und AA für betroffene elektronische Inhalte und legt damit den Text fest, anhand dessen diese gesetzliche Verpflichtung geprüft wird .

63. Bundesbehörden mussten die überarbeiteten Anforderungen von Section 508 ab Januar 2018 einhalten, vorbehaltlich der Bestimmungen und Ausnahmen der Verordnung, und die Verordnung behandelte eine zukünftige Veröffentlichung des W3C nicht als automatische Änderung .

64. Der Verweis nennt eine bestimmte Version.

65. Er wird nicht stillschweigend von 2.0 auf 2.1 oder 2.2 aktualisiert, sobald das W3C eine weitere Empfehlung veröffentlicht.

66. Ein Beschaffer auf Bundesebene kann daher nicht davon ausgehen, dass jedes neue WCAG 2.2-Kriterium bereits eine Verpflichtung gemäß Abschnitt 508 darstellt, selbst wenn das Kriterium eine echte Barriere für Personen identifiziert, die versuchen, die beschaffte Dienstleistung zu nutzen .

67. Der Beschaffer kann in einem Vertrag weiterhin höhere Anforderungen stellen, und ein Designteam kann die neueren Leitlinien freiwillig übernehmen.

68. Rechtliche Verpflichtung und gestalterische Ambitionen erfordern getrennte Formulierungen.

69. Diese Unterscheidung schützt sowohl die Rechenschaftspflicht als auch die Klarheit: Die Behörde kann darlegen, was die Vorschrift verlangt, und gleichzeitig erklären, warum ein späteres Kriterium den Zugang verbessern würde, anstatt ihre eigene Beschaffungsentscheidung auf ein Gesetz zurückzuführen, das eine ältere Version nennt.

70. Außerdem verhindert sie, dass ein Anbieter die ältere rechtliche Grundlage als Vorwand nutzt, um eine neu erkennbare Barriere zu ignorieren.

71. Das feststehende Banner macht den Unterschied greifbar.

72. Ein Tastaturbenutzer kann auf ein vollständig verdecktes Steuerelement stoßen, auf das der Fokus liegt – genau das Problem, das durch das neue WCAG 2.2 AA-Kriterium angegangen wird, unabhängig davon, ob der Ersteller der Seite eine frühere Checkliste erfüllt hat oder nicht.

73. Ein Prüfer, der ausschließlich den integrierten WCAG 2.0-Text anwendet, darf dieses Kriterium nicht als automatische Anforderung gemäß Section 508 umbenennen.

74. Eine Organisation, die WCAG 2.2 für ihre eigene Abnahmeprüfung wählt, kann direkt fragen, ob das Steuerelement zumindest teilweise sichtbar bleibt .

75. Beide Aussagen können gleichzeitig wahr sein.

76. Die in einer Regel genannte Version bestimmt deren rechtliche Prüfung; die spätere Version kann ein Problem aufdecken, dessen Behebung sinnvoll ist.

77. Versionen können auch in eine andere Richtung voneinander abweichen.

78. WCAG 2.2 hat das ältere Erfolgskriterium 4.1.1, „Parsing“, gestrichen, nachdem das W3C zu dem Schluss gekommen war, dass dessen ursprünglicher Zweck hinfällig geworden war, da assistive Technologien HTML nicht mehr direkt parsen mussten .

79. Das W3C erklärt, dass verbleibende Probleme dieser Art entweder beseitigt oder durch andere Kriterien abgedeckt sind, obwohl Entwickler weiterhin dafür sorgen müssen, dass Steuerelemente mit assistiven Technologien funktionieren .

80. Eine Korrektur kann sowohl etwas wegnehmen als auch hinzufügen.

81. Die Streichung zeigt, dass ein Test seinen Zweck verlieren kann, ohne dass das zugrunde liegende Ziel eines benutzerfreundlichen, kompatiblen Codes an Bedeutung verliert.

82. Dennoch kann eine ältere Richtlinie weiterhin auf eine Version verweisen, die dieses Kriterium enthält, und ein an diese Richtlinie gebundenes Team muss die ältere Referenz separat prüfen, anstatt davon auszugehen, dass die Streichung rückwirkend gilt.

83. Wer die Konformität mit WCAG 2.2 meldet, muss daher möglicherweise eine separate Prüfung für 4.1.1 durchführen, wenn eine anwendbare Richtlinie noch auf WCAG 2.0 oder 2.1 verweist.

84. Eine einzige Bezeichnung wie „WCAG-konform“ verbirgt zu viel.

85. Sie sollte eine Version und eine Stufe angeben und darf nicht implizieren, dass eine spätere Version eine frühere Vorschrift ersetzt hat.

86. Das W3C hat die 2.x-Reihe so konzipiert, dass sie hauptsächlich durch Ergänzungen aufgebaut wird, sodass ein Großteil der früheren Arbeit weitergeführt wird und ein Team, das eine neuere Version übernimmt, nicht jede vorherige Anforderung von Grund auf neu lernen muss.

87. Die Streichung von 4.1.1 zeigt, warum „hauptsächlich“ von Bedeutung ist.

88. Stabile Verweise und aktualisierte Leitlinien lösen unterschiedliche Probleme, und keines kann das andere einfach ersetzen.

89. Würde sich eine rechtliche Referenz automatisch ändern, könnten sich öffentliche Verpflichtungen im Rahmen eines Normungsprozesses verschieben, ohne dass die übernehmende Behörde eine bewusste Entscheidung trifft; deshalb verdient die Versionsnummer in einer Vorschrift Beachtung.

90. Würde sie sich nie ändern, könnte der übernommene Text den Anschluss an die Schwierigkeiten verlieren, die durch neuere Geräte, Praktiken und Forschungsergebnisse zutage treten, sodass Behörden weiterhin ein veraltetes Mindestmaß erfüllen müssten, während Nutzer auf Hindernisse stoßen, die der neuere Standard benennen kann.

91. Die zuständige Institution muss entscheiden, wann der Verweis überprüft werden soll, welche Belege eine Überarbeitung rechtfertigen und wie die regulierten Parteien erfahren, welche Version gilt, denn eine stillschweigende Änderung in einem Hyperlink kann diese regulierende Aufgabe nicht übernehmen .

92. Dies ist eine administrative Entscheidung mit Konsequenzen auf dem Anmeldebildschirm .

93. Eine Regierungsbehörde kann die rechtliche Quellenangabe unverändert beibehalten und den Auftragnehmern gleichzeitig ein klareres, ehrgeizigeres Ziel für ein bestimmtes Projekt vorgeben.

94. Sie muss zudem vermeiden, zu versprechen, dass eine Checkliste allein die Nutzererfahrung jedes Einzelnen regeln wird.

95. Die WCAG besagen ausdrücklich, dass selbst die höchste Konformitätsstufe nicht jede Art, jeden Grad oder jede Kombination von Behinderungen abdeckt, insbesondere dort, wo kognitive, sprachliche und lernbezogene Bedürfnisse über das hinausgehen, was die Kriterien erfassen können.

96. Die Testbarkeit des Standards ist eine Stärke mit Grenzen.

97. Ein Kriterium muss allgemein genug sein, um auf alle Websites anwendbar zu sein, und präzise genug, damit verschiedene Prüfer es bewerten können, wodurch einige Bedürfnisse außerhalb seines formalen Geltungsbereichs bleiben.

98. Das Problem ist besonders akut, wenn eine Schwierigkeit vom Kontext einer Person, von der damit verbundenen Aufgabe oder von mehreren kleinen Reibungspunkten abhängt, die zusammenwirken.

99. Eine Seite kann jedes aufgeführte Kriterium erfüllen und dennoch schwer zu bedienen sein.

100. Umgekehrt weist ein nicht erfülltes Kriterium auf einen echten Mangel hin, selbst wenn es einigen Nutzern gelingt, diesen zu umgehen .

101. Keine dieser Beobachtungen macht das Testen überflüssig.

102. Tests schaffen eine Mindestanforderung, die ein Käufer festlegen und ein Prüfer überprüfen kann, während die Beobachtung betroffener Nutzer aufzeigen kann, was diese Mindestanforderung übersieht, wenn sie eine tatsächliche Aufgabe von Anfang bis Ende ausführen.

103. Automatisierte Tools helfen dabei, einige Fehler zu lokalisieren, doch die WCAG sieht eine menschliche Bewertung als Teil der Konformitätsprüfung vor .

104. Die Beobachtung, wie Menschen den tatsächlichen Anmeldevorgang durchlaufen, wirft eine weitere Frage auf: Können sie den Dienst ohne vermeidbaren Aufwand oder Verwirrung erreichen?

105. Diese praktische Untersuchung kann ein Problem in der Abfolge der Seiten aufdecken und nicht nur in einem isolierten Steuerelement.

106. Sie kann auch einen Konflikt zwischen Sicherheitsvorkehrungen und barrierefreier Authentifizierung offenlegen, den ein Projektteam lösen muss, anstatt ihn nur zu benennen.

107. Es gibt keine Garantie dafür, dass eine Runde von Nutzertests repräsentativ für alle ist.

108. Die Rekrutierung, die gewählte Aufgabe, die verwendeten Geräte und die Art und Weise, wie die Ergebnisse interpretiert werden, prägen allesamt, was ein Team lernt; daher kann ein erfolgreicher Teilnehmer nicht stellvertretend für jede Person stehen, die den Dienst später nutzen wird .

109. Dennoch kann Feedback einem Auftraggeber aufzeigen, wo eine formal bestandene Benutzeroberfläche Mängel aufweist, und es kann als Grundlage für zukünftige Normungsarbeit dienen, wenn die Ergebnisse dokumentiert und nicht als Ausnahmen von einer bestandenen Bewertung abgetan werden.

110. Der Weg zurück in den Standard ist entscheidend.

111. In öffentlichen Stellungnahmen können neue Formulierungen vorgeschlagen werden, Arbeitsgruppen können prüfen, ob diese klar und umsetzbar sind, und veraltete Versionen können die älteren Begriffe für diejenigen beibehalten, die noch an sie gebunden sind.

112. Eine Organisation kann unterdessen zusätzliche Anforderungen für eine Beschaffung dokumentieren, ohne so zu tun, als gehörten diese bereits zur integrierten Regelung, und so sowohl die Freiheit, besseren Zugang zu fordern, als auch die Genauigkeit ihrer rechtlichen Darstellung wahren.

113. Die Alternative ist eine bekannte Verwirrung: Ein rechtliches Kontrollkästchen wird als Nachweis für uneingeschränkten Zugang behandelt, oder jede Überarbeitung wird so behandelt, als hätte sie die rechtlichen Pflichten sofort geändert.

114. Beide Verwirrungen verschleiern die Verantwortung.

115. Die Person, die die Regel verfasst, wählt die Referenz aus; der Einkäufer wählt das Projektziel; der Entwickler wählt eine Umsetzung; der Prüfer beurteilt diese anhand eines festgelegten Textes.

116. Nutzer, die immer noch auf eine Barriere stoßen, benötigen eine Möglichkeit, diese zu melden, selbst nachdem ein Test bestanden wurde, denn der Zweck eines Barrierefreiheitsstandards ist der Zugang zum Dienst und nicht eine fertige Tabellenkalkulation .

117. Jede Rolle verfügt über eine andere Art von Befugnis, und der gemeinsame Standard funktioniert nur, wenn diese Instanzen die Belege der anderen sehen und darauf reagieren können.

118. Im Anmeldefeld rutscht der Fokus immer noch hinter das feststehende Banner.

119. Die entscheidende institutionelle Errungenschaft ist nicht ein universelles Design für diesen Bildschirm, sondern ein öffentlicher Satz, der präzise genug ist, um dessen Behinderung aufzudecken, und stabil genug, um zitiert zu werden.

120. Die ebenso wichtige Entscheidung ist, ob die für den Zugang zuständigen Personen diesen Satz, seine rechtliche Grundlage und die Erfahrungen derjenigen, die versuchen, sich anzumelden, im Gespräch behalten, während sich das Web verändert.