Atrybuty aria-braille muszą mieć odpowiednik niebrajlowski.

Po co jest to sprawdzenie

To kryterium, na którym wykładają się własne komponenty. `div` ostylowany na pole wyboru nie mówi technologiom asystującym nic o tym, czy jest zaznaczony.

Co zwykle je wywołuje

• błądPrzełącznik z `<div>` bez `role="switch"` i bez `aria-checked`.
• błądPrzycisk z ikoną bez dostępnej nazwy.
• błądAkordeon, którego nagłówek nigdy nie aktualizuje `aria-expanded`.
• błądWłasny `<select>` bez `role="combobox"` i bez `aria-activedescendant`.

Jak to naprawić

• róbUżywaj natywnego elementu wszędzie tam, gdzie taki istnieje. `<button>`, `<input type="checkbox">` i `<select>` dają to wszystko za darmo.
• róbPrzy naprawdę własnym komponencie trzymaj się odpowiedniego wzorca z ARIA Authoring Practices, razem z obsługą klawiatury.
• róbTrzymaj atrybuty stanu w zgodzie z tym, co jest na ekranie.

Jak to jest raportowane

A11ySignal zgłasza to z wagą poważny. Każdy błędny element ma swój selektor CSS i kod, który zawiódł, więc trafisz prosto do właściwej linii, zamiast jej szukać. Deque publikuje szczegóły na poziomie silnika:

https://dequeuniversity.com/rules/axe/4.13/aria-braille-equivalent ↗

Sprawdzenie zaimplementowane w axe-core 4.13.0, © Deque Systems, MPL-2.0.

Inne sprawdzenia dla 4.1.2