Jump to content

Průvodce přístupností pro vývojáře

From mediawiki.org
This page is a translated version of the page Accessibility guide for developers and the translation is 100% complete.
Languages:

Přístupnost je pro naše uživatele důležitá a můžeme ji zlepšit, pokud vezmeme v úvahu pár základních nápadů a pravidel. Dostupnost je obtížná, protože neexistují žádné pevné a všeobecně uznávané technické normy, které by skutečně fungovaly konzistentně a pro všechny uživatele. Tato stránka neuvádí ani nepojednává o konkrétních problémech s přístupností v MediaWiki. Pokouší se zaměřit na výběr technologií a co dělat a co nedělat, aby se předešlo problémům s přístupností.

Pokud jde o vývoj, myslím, že toto by měla být naše kniha pravidel:

  • Pokuste se povolit našim uživatelům (a to znamená všem)
  • Pokuste se vyřešit problémy s přístupností, pokud je to možné, ale ne za každou cenu
  • Měli bychom použít přístup progresivního vylepšení oproti půvabné degradaci.
  • Implementujte věci, které jsou technologicky zdravé

Jak být přístupný

Některé důležité pojmy, které byste měli mít na paměti.

Měření přístupnosti v mnoha podobách

Přístupnost je o různých věcech, zvažte prosím následující:

  • Cokoli by mělo být srozumitelné: To znamená textově, vizuálně, logicky a komplexně.
  • Někteří uživatelé potřebují k interakci čtečku obrazovky, ale stejně, ne-li běžnější, jsou: lupa, vyšší kontrast, převodník textu na řeč, vlastní nastavení CSS nebo speciální typ klávesnice/vstupního zařízení.
  • Musí být dosažitelné. Odezva, dostupnost, umístění, jazyk, hardware atd.

Stručně řečeno, přístupnost je nejen přístupnost klávesnice nebo pouze přístupnost čtečky obrazovky. Často se zaměřujeme na tyto dva, protože jsou tradičně snadno přehlédnutelné. Ale tyto problémy jsou také řešitelné a často poskytují základ pro jakýkoli jiný druh možného vylepšení.

Některé problémy s přístupností souvisí s problémy s designem produktu, strategickými volbami, cílovým publikem atd. Vzhledem k tomu, že je obtížnější zachytit tyto oblasti v písemných pravidlech, která platí univerzálně pro ekosystém MediaWiki, jsou mimo rozsah tohoto dokumentu.

Říkáme tomu navigace pomocí klávesnice, ale ve skutečnosti to znamená: Nespoléhejte se na ukazovací zařízení (dotyk, myš).

  • Navigace pomocí klávesnice je o manipulaci se zaměřením a provádění akcí pomocí klávesnice.
  • Prvky, na které lze zaostřit pomocí tabulátoru, lze zaostřit, ale ne vše, na co lze zaostřit, lze tabulátorem.
  • Vše, co jste schopni dělat s myší, by mělo být možné dělat s klávesnicí.
  • Informace o navigaci pomocí klávesnice mohou čtečky obrazovky používat ke zlepšení svých zkušeností.

Čtečka obrazovky

  • Čtečka obrazovky používá jiný "kurzor", který obvykle prochází logickou strukturou DOM (Document Object Model (objektový model dokumentu)).
  • Fokus má tendenci sledovat kurzor čtečky obrazovky a naopak, ale nejsou stejné
    • Zaměřený prvek můžete sledovat nastavením živého výrazu v prohlížeči Chrome [1]
  • Čtečka obrazovky používá rozhraní API 'přístupnosti“', kterou byste mohli považovat za vstupní/výstupní 'zobrazení' nad normálním DOM.
  • ARIA jsou anotace DOM, které vylepšují nebo upravují způsob, jakým je logika DOM transformována do rozhraní API pro usnadnění. Není to alternativa k psaní správného HTML a JavaScriptu. Navigace pomocí klávesnice je jednoduše dosaženo logickým pořadím DOMǃ Více o ARIA viz vysvětlení w3.org a vysvětlení MDN.
  • Čtečka obrazovky není omezena na navigaci podle logické struktury DOM, je pouze výchozí.
    • Čtečka obrazovky může například číst, co je pod ukazatelem myši
    • VoiceOver pro iOS používá kurzor na obrazovce, který se ovládá polohováním palce a gesty na dotykové obrazovce.
    • Většina softwaru pro čtení obrazovky má další režimy navigace, kde můžete vytvářet seznamy a procházet podle oblastí orientačních bodů, automaticky generovaný obsah nebo dokonce uživatelem definované 'záložky' uvnitř stránky.
  • Z výše uvedeného bodu několika navigačních metod vyplývá: Existuje začátek a konec, ale také vlevo, vpravo, nahoře a dole. Neměli byste na ně ve své komunikaci příliš spoléhat, ale ani jejich existenci nemusíte zcela popírat. Nezaměňujte vizuální schopnosti uživatele s prostorovým povědomím, které může být čtenáři obrazovky schopen sdělit uživateli. Příklad:
    1. dlouhá věta [obrázek] výše uvedený obrázek ukazuje... Still acceptable
    2. dlouhá věta [obrázek][obrázek] levý obrázek ukazuje, pravý obrázek ukazuje... Still acceptable
    3. dlouhá věta [obrázek][obrázek] pravý obrázek ukazuje, levý obrázek ukazuje... Not acceptable
    4. dlouhá věta [image][image] výše uvedený obrázek ukazuje... Not acceptable
    5. dlouhá věta [obrázek][obrázek][obrázek] levý obrázek ukazuje, pravý obrázek ukazuje... Not acceptable
    6. dlouhá věta [image][image] něco úplně jiného. levý obrázek ukazuje, pravý obrázek ukazuje... Definitely not acceptable

Pokyny pro vývoj

Existuje několik standardů týkajících se přístupnosti a upřímně řečeno, téměř všechny z nich, i když jsou správné na identifikaci problémů, mají stále značné problémy, pokud jde o technická řešení (mají vysoký podíl "nepěkných řešení"). To bylo příčinou mnoha kontroverzí v komunitách. Jako takové bychom měli identifikovat nekontroverzní věci, které bychom prostě měli vždy (nebo nikdy) dělat a proč. Je mnohem snazší dosáhnout určitých cílů, pokud oddělíme nekontroverzní věci od kontroverzních věcí.

Vždy používejte nebo poskytujte

Správný sémantický prvek HTML
Používejte prvky HTML pro jejich zamýšlený účel. Například:
  • Použijte ‎<button> a ne ‎<div>, ‎<span> nebo ‎<a> s obsluhou kliknutí
  • Pokud máte pocit, že je potřeba něco zvýraznit tučným písmem, zvažte, zda není vhodnější použít záhlaví nebo prvek strong
Logická struktura nadpisů
Všechny stránky by vždy měly mít logickou a konzistentní strukturu nadpisů. Nadpisy jsou jedním z primárních navigačních nástrojů používaných uživateli čteček obrazovky.
  1. Ve vnoření úrovní nadpisů by neměly být žádné úrovně vynechány. (Takže ne H2->H4.)
  2. Nadpisy by měly být popisné
  3. Nadpisy by měly být jedinečné v rámci své vlastní úrovně. (Ve stejné sekci H2 by neměly být dvě H3 se stejným obsahem)
  4. Mezi navigací a obsahem by mělo být oddělení
Atribut alt pro obrázky se smysluplnými hodnotami
Pokud je obrázek dekorativní, použijte explicitní prázdnou hodnotu pro atribut alt; ještě lépe, přeměňte jej na obrázek pozadí CSS.
alt obrázku má obvykle přednost před atributem title obrázků a dokonce i před atributem title odkazů, které obtékají obrázek.
Atribut title pro odkazy
Ty se obvykle zobrazují jako popisky
Názvy používejte pouze v případě, že se liší od textu odkazu.
Většinu názvů odkazů ve skutečnosti čtečky obrazovky nevyslovují, pokud není čtečka takto výslovně nakonfigurována.
Atributy lang, dir a hreflang
Použití lang a hreflang umožňuje vybrat správný hlas ve čtečkách obrazovky, vybrat správnou opravu pravopisu v prohlížečích atd.
Dostatečný kontrast
Vždy zkontrolujte, zda jsou barvy dostatečně kontrastní. U textu je potřeba vyšší kontrast pro menší text (kvůli vyhlazování).
Zaměření na navigaci pomocí klávesnice
Proveďte not pro odstranění obrysů (remove outline) ze zaměřených prvků, pokud nedefinujete svůj vlastní obrys pro stav :focus.
  • Jinak nepoužívejte outline: 0.
  • Pokud definujete jakoukoli pseudotřídu, například :hover nebo :active, definujte také styl :focus.
Navigace pomocí klávesnice
Interaktivní prvky stránky by měly umožňovat navigaci pomocí klávesnice. Ujistěte se, prosím, že je ve vašem prohlížeči povolena navigace klávesou tabulátoru a umožňuje vám ovládat každý interaktivní prvek bez použití ukazovacího zařízení.
  1. Pomocí tabIndex: 0 zpřístupněte klávesnici prvků, které nejsou z klávesnice přístupné implicitně (Cokoliv kromě ‎<a>, ‎<area>, ‎<button>, ‎<input>, ‎<object>, ‎<select>, ‎<textarea>).
    1. V tomto případě přidejte také handler keydown reagující na Enter (keyCode 13) a mezeru (keyCode 32).
  2. Pomocí tabindex: -1 odeberte prvky z usnadnění. (použijte to u odkazů, které jsou například štítky pro akci uvnitř ‎<li>...‎</li>)
  3. Prvky, které jsou implicitně přístupné z klávesnice, budou přesměrovány klávesou Enter/mezerník dolů na manipulátor kliknutí
Dialogy atd.

Když se dobře nestaráte o přístupnost, jsou dialogy některé z nejhůře přístupných prvků pro uživatele čtečky obrazovky a klávesnice. Věnujte tomu nějaký čas.

  • Prvek, který otevře dialogové okno, by měl mít aria-haspopup
  • Samotný dialog by měl mít role=[dialog | alertdialog | tooltip]
  • Dialog by měl být vložen v pořadí DOM, [1] nebo aria vlastní/ovládá musí specifikovat tento vztah mezi otevíracím prvkem a dialogem
  • Při otevírání dialogu si zapamatujte poslední vybraný prvek a přesuňte fokus na první zaměřitelný prvek s tabelátorem uvnitř dialogu
  • Když je dialog modální, znemožní interakci se zbytkem stránky
    • Zachyťte kliknutí mimo dialog a ignorujte je nebo je nechte dialog zavřít
    • Ujistěte se, že nemůžete tabulátorem procházet odkazy nebo vkládat prvky mimo dialog
    • Udělejte prvky mimo dialogové okno nedostupné pro čtečku obrazovky pomocí aria-hidden
  • Ujistěte se, že existuje režim zavření (klávesa Esc a zaostřitelné tlačítko zavření s popisným názvem)
  • Zavření by mělo vrátit fokus (klávesnice) na původní zaostřovací bod, který jste uložili při otevření dialogu. Aby se čtečky obrazovky vrátily do stejného bodu, nezapomeňte zadat pravého vlastníka dialogu, pokud jste dialog nevložili v pořadí DOM.
  • Přečtěte si: Aria modaly, Aria modální dialog, ARIA nemodální dialog, ARIA popisky.
WCAG 2.1 pravidla
Sledujte, kde je to možné
A jeho doprovodné dokumenty:

Co opravdu ne

  • Existuje běžná rada použít left: -1000px k vytlačení něčeho (často označení tlačítek ikon) z výřezu pro vizuální uživatele a stále to mít v DOM přístupnosti. text-indent: -9999px je variantou tohoto. Tohle je ŠPATNÁ rada.
    • To narušuje naše zobrazení RTL v několika prohlížečích. Konkrétně v režimu rtl vytváří velké plátno vlevo od výřezu a posuvníků, stejně jako +1000px by vytvořilo v režimu ltr. (V případě potřeby, aby se tomu zabránilo, je preferován top: -1000px před left: -1000px).
    • VoiceOver na mobilu nemůže tento text použít jako záložní, protože se jedná o 'poziční' čtečku obrazovky. Po tomto textu nemůžete pohybovat prstem, a proto se text ani nepřečte. (aria-label je často lepší volbou).
    • Nakonec se tím zvětší plocha vykreslování potřebná k výpočtu konečné webové stránky, což může ovlivnit výkon [2] na mobilních zařízeních.
    • Jonathan Snook poskytuje srozumitelný přehled triků 'skrýt text mimo obrazovku'.
  • Věci by se neměly často opakovat. Pokud máte na stránce 100 odkazů, které mohou otevřít dialogové okno, pak k těmto 100 odkazům nepřidávejte 100 štítků, které uživateli říkají, že je lze použít k otevření dialogu. Říkat uživateli, jak používat/co dělat s rozhraním, je dobrá věc, dělat to důsledně je prostě otravné. Najděte jiný způsob, jak to jednou vysvětlit (v tomto případě může být nápad aria-live=polite?).
  • <a href="#">Hide</a> s obsluhou onclick. VO čte takový JS jako "interní odkaz Hide". Použijte správné tlačítko nebo <a role="button" tabindex="0">Hide</a> s obslužnými nástroji kláves 'Mezerník' a 'Enter' v onclick. Ale žádný atribut href.
  • Nevnořujte interaktivní funkce do jiného interaktivního prvku (odkazy nebo tlačítka uvnitř odkazů). To mate čtečky obrazovky.

Vyhněte se

Symboly Unicode
Většina asistenčních technologií není dobrá se symboly. Proto se snažte vyhýbat znakům, jako jsou ↑, →‎ nebo složitějším znakům, protože mnoho programů pro čtení z obrazovky jim nebude rozumět. Pokud jsou vyžadovány, zkuste je zabalit do prvku span s atributem title, aby atribut title mohl čtenáři sdělit implicitní význam v kontextu.
Malá písmena
Upřednostňuje se čitelnost. Pokud uděláte něco tak malého, že se to špatně čte, potřebujete to pro začátek vůbec? Vyhněte se také malým písmům s nízkými nebo průměrnými hodnotami kontrastu (i když spadají do pokynů WCAG, malé velikosti vyžadují jasnější kontrast než velké velikosti, zejména s povoleným vyhlazováním).
Neobvykle velká písmena
Pokud uděláte text mnohem větší, než je obvyklé, může být podobně špatně čitelný (pokud není příliš krátký). To se týká většinou hlavního textu nebo čehokoli, co zabírá více než několik řádků. Ale čím větší je text, tím více řádků zabere.
tabIndex > 0
Objednávka DOM je preferována všude tam, kde je to možné. Pořadí DOM poskytuje kontext pro akce.
Řešení
Dosažení 'plné' dostupnosti tradičně vyžadovalo mnoho řešení pro samotný html, prohlížeče a dokonce i specifický software pro čtení obrazovky. Tato řešení však často přicházejí s vedlejšími účinky, využívají chyby nebo blíže nespecifikované chování a nevyhnutelně vytvářejí technický dluh.
MediaWiki, kvůli uživatelům, kterým se snaží sloužit, množství kódu, (nedostatek) financí atd. má tendenci upřednostňovat budoucí zkušební kód před kódem, který se snadno rozbije. Jako takový se obecně vyhýbá řešením, i když to může někdy omezit dostupnost, kterou můžeme poskytnout. Rozhodnutí o tom jsou často ovlivněna relativním publikem funkce na MediaWiki. Pokud je něco všudypřítomné pro všechny uživatele, řešení je opodstatněnější, než když dotčenou funkci používá pouze malá část publika (například čtení stránky nebo úprava konfigurace instalace).

Zvažte

  • Role ARIA
    • Pokud se div nebo span chová jako skutečné tlačítko, použijte role="button". také role="dialog" a role="alert"
    • Buďte opatrní s rolemi. Nepřidávejte například role="button" k prvku ‎<th>, protože prvek ‎<th> má implicitní hodnotu role="columnheader", která bude přepsána. Místo toho použijte vnořené prvky. Podobně pro ‎<li>, který má implicitní role="listitem"
    • Pokud tlačítko vytvoří vyskakovací dialog, použijte aria-haspopup.
    • Použijte aria-labelled-by pro kontexty, kde to samo o sobě není zcela logické (takže všude kromě štítků ve formulářích a záhlaví v tabulkách).
  • Vyhněte se tabulkám pro účely rozvržení a testujte na menších šířkách obrazovky.
  • Skrýt věci: https://www.tpgi.com/html5-accessibility-chops-hidden-and-aria-hidden/
  • Přeskočit/přeskočit na odkazy

Související odkazy

Poznámky pod čarou

  1. ↑ Podívejte se na stránky Objednávka DOM na w3.org a Pořadí stylu Property na w3schools.org
Retrieved from "https://www.mediawiki.org/w/index.php?title=Accessibility_guide_for_developers/cs&oldid=6335282"