[:pl]Dostępność cyfrowa formularzy a WCAG 2.1[:en]Accessibility of web forms in WCAG 2.1[:]

[:pl]

Dążąc do zapewnienia dostępności cyfrowej, czy to ze względu na wymagania prawne, czy oczekiwania rynku, sięgamy najpierw do standardu WCAG 2.1, powtórzonego w normach europejskich (Web Content Accessibility Guidelines 2.1 z 2018 r. jest częścią normy EN 301 549).

Jednak podział kryteriów sukcesu, bo takim terminem posługuje się standard WCAG, jest przyjęty w sposób pozwalający na kategoryzowanie zagadnień informatycznych, jednak nie sposobów, w jaki postrzegamy serwisy internetowe.

Dobrym przykładem tego problemu są błędy formularzy. Trudno znaleźć omówienie problematyki dostępności cyfrowej formularzy, która nie odwoływałaby się do więcej, niż jednej wytycznej WCAG.
Jakie zestawienie kryteriów sukcesu najczęściej kojarzone jest z dostępnością formularzy?
Po pierwsze, podaje się zasadę 1.3.1: Informacje i relacje. Jest to wytyczna z kryterium sukcesu poziomu A w obrębie zasady 1 – postrzegalność. Zasady WCAG 2.1 wskazują, że przy spełnieniu tej wytycznej, informacje, struktura oraz relacje między treściami przekazywane poprzez prezentację mogą być odczytane przez program komputerowy lub istnieją w postaci tekstu.

Po drugie, pojawia się zasada 2.4.6: Nagłówki i etykiety. Jest to wytyczna z kryterium sukcesu poziomu AA w obrębie zasady 2 – funkcjonalność. Zasady WCAG 2.1 wskazują, że przy spełnieniu tej wytycznej, nagłówki i etykiety opisują temat lub cel treści.

Po trzecie, wymienia się zasadę 3.3.2: Etykiety lub instrukcje. Jest to wytyczna z kryterium sukcesu poziomu A w obrębie zasady 3 – zrozumiałość. Zasady WCAG 2.1 wskazują, że przy spełnieniu tej wytycznej, gdy w treści wymagane jest wprowadzenie danych przez użytkownika, zapewnione są etykiety lub instrukcje.

Po czwarte, wskazywana jest zasada 4.1.2: Nazwa, rola, wartość. Jest to wytyczna z kryterium sukcesu na poziomie A i dotyczy zasady 4 – solidność. Oznacza, że dla wszystkich komponentów interfejsu użytkownika (w tym, ale nie tylko, elementów formularzy, łączy oraz komponentów wygenerowanych przez skrypty) nazwa oraz rola mogą być określone programowo ; stan, właściwości oraz wartości, które mogą być ustawione przez użytkownika, mogą również być ustawione programowo ; powiadomienie o zmianach w tych elementach dostępne jest dla programów użytkownika , w tym technologii wspomagających.

Zrozumienie tych zasad w kontekście tworzenia formularzy nie jest łatwe. W uproszczeniu, formularze powinny być zaprogramowane w klasyczny sposób i wyczerpująco: zawierać nie tylko przykładową treść, ale także etykietę (label), odpowiednio się „fokusować” przy pomocy klawiatury i – osobno – czytnika ekranu, jednakowo dla TAB i strzałki oraz przez użycie skrótu (np. E przez NVDA). Formularz powinien mieć ustawione wartości autouzupełniania, nie mieć ukrytych elementów, a także informować w sposób tekstowy (nie znakami specjalnymi i nie kolorami), jak formularz ma być wypełniony – na przykład, które pola są obowiązkowe. W przypadku komunikatów wizualnych, nietekstowych, naruszone są jeszcze inne wytyczne WCAG 2.1, niż wyżej wymienione (np. wytyczna 1.4.1, kryterium A, podczas, gdy oznaczania znakami specjalnymi dotyczy wytyczna 1.3.1, wskazana wcześniej).

Pochodną prawidłowego zaprogramowania formularza jest prawidłowe komunikowanie o błędzie. Komunikat taki musi być dostępny dla osób, które wypełniają formularz przez czytnik ekranu (np. odsłuchiwać się przez NVDA, w języku danej strony). Jest to związane z wytyczną 3.3.1 (poziom A).

Zewnętrzne materiały: WCAG 2.1 https://www.w3.org/Translations/WCAG21-pl/

[:en]

When striving for digital accessibility, whether due to legal requirements or market expectations, we look first to the WCAG 2.1 standard, echoed in European standards (the 2018 Web Content Accessibility Guidelines 2.1 is part of EN 301 549).

However, the division of success criteria, as this is the term used by the WCAG standard, is adopted to categorize IT issues, but not the ways in which we perceive websites.

Form errors are a good example of this problem. It is difficult to find a discussion of the digital accessibility of forms that does not refer to more than one WCAG guideline.
What set of success criteria is most often associated with form accessibility?
First, there is Principle 1.3.1: Information and Relationships. This is a guideline from the Level A success criterion within Principle 1 – Perceivability. WCAG Principles 2.1 indicates that when this guideline is met, the information, structure, and relationships between content conveyed through the presentation can be read by a computer program or exist in text form.

Second, comes rule 2.4.6: Headings and Labels. This is a guideline from the AA level success criterion within Principle 2 – Functionality. WCAG Principles 2.1 indicates that when this guideline is met, headings and labels describe the topic or purpose of the content.

Third, Principle 3.3.2: Labels or Instructions is mentioned. This is a guideline from the Level A success criterion within Principle 3 – understandability. The WCAG 2.1 principles indicate that when this guideline is met, labels or instructions are provided when user input is required in the content.

Fourth, principle 4.1.2 is indicated: name, role, value. This is a guideline with a level A success criterion and relates to principle 4 – robustness. It means that for all user interface components (including, but not limited to, form elements, links, and script-generated components), the name and role can be specified programmatically ; the state, properties, and values that can be set by the user can also be set programmatically ; notification of changes to these elements is available to user programs , including assistive technologies.

Understanding these principles in the context of form development is not easy. In simple terms, forms should be programmed in a classic and comprehensive way: contain not only sample content, but also a label, properly „focus” using the keyboard and – separately – the screen reader, equally for TAB and arrow and by using a shortcut (e.g. E by NVDA). The form should have autocomplete values set, have no hidden elements, and communicate in text (not special characters or colors) how the form is to be filled out – for example, which fields are mandatory. In the case of visual, non-textual messages, there are violations of WCAG 2.1 guidelines other than those mentioned above (e.g., guideline 1.4.1, criterion A, while special markings apply to guideline 1.3.1, indicated earlier).

A derivative of correct programming of the form is correct error communication. Such a message must be available to those who fill out the form through a screen reader (e.g., listen through NVDA, in the language of the page). This is related to guideline 3.3.1 (level A).

External resources: WCAG 2.1 https://www.w3.org/Translations/WCAG21-pl/

 

[:]