diff --git a/assets/ico-language.svg b/assets/ico-language.svg index 408145f..3a6678c 100644 --- a/assets/ico-language.svg +++ b/assets/ico-language.svg @@ -2,4 +2,4 @@ - \ No newline at end of file + diff --git a/assets/ico-published.svg b/assets/ico-published.svg index dab741d..3439483 100644 --- a/assets/ico-published.svg +++ b/assets/ico-published.svg @@ -3,4 +3,4 @@ - \ No newline at end of file + diff --git a/assets/ico-rss.svg b/assets/ico-rss.svg index 78bf6ed..b5485db 100644 --- a/assets/ico-rss.svg +++ b/assets/ico-rss.svg @@ -2,4 +2,4 @@ - \ No newline at end of file + diff --git a/assets/ico-updated.svg b/assets/ico-updated.svg index cf40e33..e90577a 100644 --- a/assets/ico-updated.svg +++ b/assets/ico-updated.svg @@ -3,4 +3,4 @@ - \ No newline at end of file + diff --git a/assets/logo.svg b/assets/logo.svg index 4b05ca0..03d6f18 100644 --- a/assets/logo.svg +++ b/assets/logo.svg @@ -5,4 +5,4 @@ - \ No newline at end of file + diff --git a/assets/wave.svg b/assets/wave.svg index d2b3777..54f284a 100644 --- a/assets/wave.svg +++ b/assets/wave.svg @@ -1,3 +1,3 @@ - \ No newline at end of file + diff --git a/en/404.html b/en/404.html index 7c89bcf..8faccc9 100644 --- a/en/404.html +++ b/en/404.html @@ -1 +1 @@ -Page not found — Blog on Digital Accessibility

Page not found

Most likely, such a page does not exist.

Go back to the main page

Tatiana Fokina, 2021–2024
Build on 11ty, icons by Lucide Find an issue? Let me know on GitHub
\ No newline at end of file +Page not found — Blog on Digital Accessibility

Page not found

Most likely, such a page does not exist.

Go back to the main page

Tatiana Fokina, 2021–2024
Build on 11ty, icons by Lucide Find an issue? Let me know on GitHub
\ No newline at end of file diff --git a/en/articles/aria-attribute-role-with-multiple-values/index.html b/en/articles/aria-attribute-role-with-multiple-values/index.html index 008698a..6b13cfe 100644 --- a/en/articles/aria-attribute-role-with-multiple-values/index.html +++ b/en/articles/aria-attribute-role-with-multiple-values/index.html @@ -21,7 +21,7 @@ }, "datePublished": "2024-06-03T00:00:00.000Z", "dateModified": "2024-06-28T00:00:00.000Z" - }

Role attribute with multiple values

  • ARIA
  • HTML
Updated:

Recently, I discovered by chance that the role attribute may contain more than one value. This was very unexpected, at least for me.

So, I wrote this post out of research interest, so it doesn't contain much practical advice. In fact, some of it's better not put into practice.

Background on roles

Roles contain information on functions of elments, and how it can be interacted with. For example, screen readers will announce that the button element has the button role which means that this element is clicable.

Elements can have either implicit or explicit roles. The latter are specified in the role attribute.

There are many categories of roles, each with clear rules for their explicit usage. For instance, you can't change roles during interaction with an element, or set abstract roles, such as landmark, section, widget, etc. There are also roles that assume nested elements. For example, an element with role="menu" must have at least one menuitem element nested within it. However, the main rule is to set roles explicitly as rarely as possible, especially to avoid overriding semantics of elements.

What standards and specifications say?

In WAI-ARIA (Web Accessibility Initiative - Accessible Rich Internet Applications), as the most obvious source about roles, there are no examples with two values for the attribute. I had to look up information about the multiple values in this case.

WAI-ARIA

Clause 7.1 Role Attribute in WAI-ARIA 1.1 contains the characteristics of the role attribute that should be considered in a host languages:

  • The attribute name MUST be role;
  • The attribute value MUST allow a token list as the value;
  • The appearance of the name literal of any concrete WAI-ARIA role as one of these tokens MUST NOT in and of itself make the attribute value illegal in the host-language syntax; and
  • The first name literal of a non-abstract WAI-ARIA role in the list of tokens in the role attribute defines the role according to which the user agent MUST process the element. User Agent processing for roles is defined in the Core Accessibility API Mappings 1.1.

Clauses 8.1 Role Attribute of WAI-ARIA versions 1.2 and 1.3 provides almost the same description:

  • The attribute value MUST allow a token list as the value;
  • The appearance of the name literal of any concrete WAI-ARIA role as one of these tokens MUST NOT in and of itself make the attribute value illegal in the host-language syntax; and
  • The first name literal of a non-abstract WAI-ARIA role in the list of tokens in the role attribute defines the role according to which the user agent MUST process the element. User Agent processing for roles is defined in the Core Accessibility API Mappings 1.2.

Since all versions of WAI-ARIA refers to other documentation, let is read it now.

Core Accessibility API Mappings

Core Accessibility API Mappings (Core-AAM for short) is a specification for browsers and other user agents. It describes how they must interact with Accessibility API.

Clause 5.4 Role mapping of Core-AAM 1.1 says what we want to find out:

Traditionally Accessibility API platforms have a limited set of predefined roles that are expected by assistive technologies on that platform, and only one or two roles can be provided. In contrast, WAI-ARIA allows multiple roles to be specified as an ordered set of valid role tokens separated by spaces. Additional roles are fallback for other roles, which is similar to the concept of specifying multiple fonts in case the first font type isn't supported.

This part of the document collects rules for roles themselves.

  1. The user agent MUST use the first token in the sequence of tokens in the role attribute value which matches the name of any non-abstract WAI-ARIA role according to rules that are specified in the Role Mapping Table below. Note that when WAI-ARIA roles override host language semantics, there are no changes in the DOM, only in the accessibility tree.
  2. User agents MUST NOT map roles defined in the WAI-ARIA specification as "abstract" via the standard role mechanism of the accessibility API.

In Core-AAM 1.2 you find almost the same information, but also more details about roles supporting by different Accessibility APIs.

HTML standard

A long time ago in HTML standard there was Clause 3.2.7.3.1 ARIA Role Attribute. It described the ability to add multiple roles for one element:

Every HTML element may have an ARIA role attribute specified. This is an ARIA Role attribute as defined by ARIA Section 5.4 Definition of Roles.
The attribute, if specified, must have a value that is a set of space-separated tokens representing the various WAI-ARIA roles that the element belongs to.
The WAI-ARIA role that an HTML element has assigned to it is the first non-abstract role found in the list of values generated when the role attribute is split on spaces.

This clause doesn't exist anymore, but the Internet never forgets.

Put it simple

What conclusions can be drawn after exploring the specifications?

  • Multiple values can be specified for role
  • Multiple values are listed with spaces between them
  • Multiple roles are needed for fallback. If the first role isn't supported or doesn't exist, the second one is applied, and so on
  • If it is an abstract role, browsers and screen readers will ignore it.

Let is testing

Now we are going to check what browsers and screen readers will do with two values for role. We will experiment in Chrome 97, Firefox 96, and Safari 14 with NVDA 2021.2 and desktop version of VoiceOver.

By the way, in old browsers and screen readers, this cannot be tested. They simply ignore role="" with multiple values. Keep this in mind.

The markup I will be testing might be scary. This is a test of the single attribute, so I decided to use forbidden techniques at least once in my life 😀. In real projects, it's better never to do this. This is a terrible anti-pattern (and can be consider as a crime, ha-ha.)

Two valid values

<div
+		}
 
Role attribute with multiple values
  • ARIA
  • HTML
 
 Updated: 
Recently, I discovered by chance that the role attribute may contain more than one value. This was very unexpected, at least for me.
So, I wrote this post out of research interest, so it doesn't contain much practical advice. In fact, some of it's better not put into practice.
Background on roles
Roles contain information on functions of elments, and how it can be interacted with. For example, screen readers will announce that the button element has the button role which means that this element is clicable.
Elements can have either implicit or explicit roles. The latter are specified in the role attribute.
There are many categories of roles, each with clear rules for their explicit usage. For instance, you can't change roles during interaction with an element, or set abstract roles, such as landmark, section, widget, etc. There are also roles that assume nested elements. For example, an element with role="menu" must have at least one menuitem element nested within it. However, the main rule is to set roles explicitly as rarely as possible, especially to avoid overriding semantics of elements.
What standards and specifications say?
In WAI-ARIA (Web Accessibility Initiative - Accessible Rich Internet Applications), as the most obvious source about roles, there are no examples with two values for the attribute. I had to look up information about the multiple values in this case.
WAI-ARIA
Clause 7.1 Role Attribute in WAI-ARIA 1.1 contains the characteristics of the role attribute that should be considered in a host languages:
  • The attribute name MUST be role;
  • The attribute value MUST allow a token list as the value;
  • The appearance of the name literal of any concrete WAI-ARIA role as one of these tokens MUST NOT in and of itself make the attribute value illegal in the host-language syntax; and
  • The first name literal of a non-abstract WAI-ARIA role in the list of tokens in the role attribute defines the role according to which the user agent MUST process the element. User Agent processing for roles is defined in the Core Accessibility API Mappings 1.1.
Clauses 8.1 Role Attribute of WAI-ARIA versions 1.2 and 1.3 provides almost the same description:
  • The attribute value MUST allow a token list as the value;
  • The appearance of the name literal of any concrete WAI-ARIA role as one of these tokens MUST NOT in and of itself make the attribute value illegal in the host-language syntax; and
  • The first name literal of a non-abstract WAI-ARIA role in the list of tokens in the role attribute defines the role according to which the user agent MUST process the element. User Agent processing for roles is defined in the Core Accessibility API Mappings 1.2.
Since all versions of WAI-ARIA refers to other documentation, let is read it now.
Core Accessibility API Mappings
Core Accessibility API Mappings (Core-AAM for short) is a specification for browsers and other user agents. It describes how they must interact with Accessibility API.
Clause 5.4 Role mapping of Core-AAM 1.1 says what we want to find out:
Traditionally Accessibility API platforms have a limited set of predefined roles that are expected by assistive technologies on that platform, and only one or two roles can be provided. In contrast, WAI-ARIA allows multiple roles to be specified as an ordered set of valid role tokens separated by spaces. Additional roles are fallback for other roles, which is similar to the concept of specifying multiple fonts in case the first font type isn't supported.
This part of the document collects rules for roles themselves.
  1. The user agent MUST use the first token in the sequence of tokens in the role attribute value which matches the name of any non-abstract WAI-ARIA role according to rules that are specified in the Role Mapping Table below. Note that when WAI-ARIA roles override host language semantics, there are no changes in the DOM, only in the accessibility tree.
  2. User agents MUST NOT map roles defined in the WAI-ARIA specification as "abstract" via the standard role mechanism of the accessibility API.
In Core-AAM 1.2 you find almost the same information, but also more details about roles supporting by different Accessibility APIs.
HTML standard
A long time ago in HTML standard there was Clause 3.2.7.3.1 ARIA Role Attribute. It described the ability to add multiple roles for one element:
Every HTML element may have an ARIA role attribute specified. This is an ARIA Role attribute as defined by ARIA Section 5.4 Definition of Roles.
The attribute, if specified, must have a value that is a set of space-separated tokens representing the various WAI-ARIA roles that the element belongs to.
The WAI-ARIA role that an HTML element has assigned to it is the first non-abstract role found in the list of values generated when the role attribute is split on spaces.
This clause doesn't exist anymore, but the Internet never forgets.
Put it simple
What conclusions can be drawn after exploring the specifications?
  • Multiple values can be specified for role
  • Multiple values are listed with spaces between them
  • Multiple roles are needed for fallback. If the first role isn't supported or doesn't exist, the second one is applied, and so on
  • If it is an abstract role, browsers and screen readers will ignore it.
Let is testing
Now we are going to check what browsers and screen readers will do with two values for role. We will experiment in Chrome 97, Firefox 96, and Safari 14 with NVDA 2021.2 and desktop version of VoiceOver.
By the way, in old browsers and screen readers, this cannot be tested. They simply ignore role="" with multiple values. Keep this in mind.
The markup I will be testing might be scary. This is a test of the single attribute, so I decided to use forbidden techniques at least once in my life 😀. In real projects, it's better never to do this. This is a terrible anti-pattern (and can be consider as a crime, ha-ha.)
Two valid values
<div
   role="button link"
   aria-label="This is not a button"
   tabindex="1"
diff --git a/en/articles/aria-live-regions/index.html b/en/articles/aria-live-regions/index.html
index b61d52d..c8b8589 100644
--- a/en/articles/aria-live-regions/index.html
+++ b/en/articles/aria-live-regions/index.html
@@ -21,7 +21,7 @@
 			},
 			"datePublished": "2024-05-11T00:00:00.000Z",
 			"dateModified": "2024-09-02T00:00:00.000Z"
-		}
 
What you need to know about ARIA live regions
  • ARIA
  • HTML
  • Screen readers
 
 Updated: 
(This is a translation of my Russian-language article from Web Standards edited by Vadim Makeev and Olga Aleksashenko. I've also rewritten some parts and provided more details based on ″What Live Regions are?″ on Doka Guide).
If you have a dynamically changing part of a page and you're thinking about making it accessible, you may wonder how to do it. This could apply to:
  • Chats
  • Progress bars and timers
  • News and weather widgets
  • Alerts and notifications (new messages, likes, subscriptions)
  • Currency rates and tickers (stock quotes, indices, bonds)
  • Sports statistics, and more.
Previously, assistive technologies (particularly screen readers) couldn't properly process these dynamic elements. Users wouldn't know about errors or new data until they returned to a previous section or reached the end of the page. Now the accessibility of dynamically changing content can be addressed using ARIA.
If you're unfamiliar with this acronym, WAI-ARIA or simply ARIA (Web Accessibility Initiative - Accessible Rich Internet Applications) is a standard consisting of special roles and attributes added to markup. These roles and attributes extend or augment the functionality of standard HTML elements or elements in another programming host languages.
To create a dynamic (″alive″) part of the page where changes occur, we need to implement what ARIA terminology calls a ″Live Region″. The WAI-ARIA 1.2 standard defines a live region as follows:
Live Regions are perceived areas of pages that are usually updated as a result of an external event when a user focuses somewhere else. These regions are not always updated due to user interaction with an UI. This practice has become commonplace as a result of the heavy use of Ajax.
Thus, by using live regions, we can ensure that users of screen readers are informed about important changes on the page, even when they set keyboard focus on a different element.
First of all, we need to create changes on a page. Basically, it's all about manipulating HTML elements and their content. For that, you can do these:
  • Add or delete a content as the page loads or after it's refreshed
  • Add or delete an element to the page using JavaScript
  • Change or add only the content of an element while keeping the element itself on the page
  • Change the value of the display CSS property from none to block, or visibility from hidden to visible
  • Add or remove the hidden HTML attribute from an element.
The second step is all about creating a live region where any of the changes from the previous list happen. For this purpose, we have two options: Use native HTML elements and a set of special ARIA roles and attributes. Once implemented, changes to all child elements within the live region will become accessible to screen readers.
HTML elements
Unfortunately, there are not many native HTML elements for live regions (at least for now). One of them is the <output> element.
<output> used to display results. These could be mathematical calculations or the correct missing word in a sentence for grammar tests. Another less obvious use case is for pop-up notifications or toasts 🧇. These are alerts that slide in at the bottom or top of the screen and disappear after some time.
<button>Save</button>
+		}
 
What you need to know about ARIA live regions
  • ARIA
  • HTML
  • Screen readers
 
 Updated: 
(This is a translation of my Russian-language article from Web Standards edited by Vadim Makeev and Olga Aleksashenko. I've also rewritten some parts and provided more details based on ″What Live Regions are?″ on Doka Guide).
If you have a dynamically changing part of a page and you're thinking about making it accessible, you may wonder how to do it. This could apply to:
  • Chats
  • Progress bars and timers
  • News and weather widgets
  • Alerts and notifications (new messages, likes, subscriptions)
  • Currency rates and tickers (stock quotes, indices, bonds)
  • Sports statistics, and more.
Previously, assistive technologies (particularly screen readers) couldn't properly process these dynamic elements. Users wouldn't know about errors or new data until they returned to a previous section or reached the end of the page. Now the accessibility of dynamically changing content can be addressed using ARIA.
If you're unfamiliar with this acronym, WAI-ARIA or simply ARIA (Web Accessibility Initiative - Accessible Rich Internet Applications) is a standard consisting of special roles and attributes added to markup. These roles and attributes extend or augment the functionality of standard HTML elements or elements in another programming host languages.
To create a dynamic (″alive″) part of the page where changes occur, we need to implement what ARIA terminology calls a ″Live Region″. The WAI-ARIA 1.2 standard defines a live region as follows:
Live Regions are perceived areas of pages that are usually updated as a result of an external event when a user focuses somewhere else. These regions are not always updated due to user interaction with an UI. This practice has become commonplace as a result of the heavy use of Ajax.
Thus, by using live regions, we can ensure that users of screen readers are informed about important changes on the page, even when they set keyboard focus on a different element.
First of all, we need to create changes on a page. Basically, it's all about manipulating HTML elements and their content. For that, you can do these:
  • Add or delete a content as the page loads or after it's refreshed
  • Add or delete an element to the page using JavaScript
  • Change or add only the content of an element while keeping the element itself on the page
  • Change the value of the display CSS property from none to block, or visibility from hidden to visible
  • Add or remove the hidden HTML attribute from an element.
The second step is all about creating a live region where any of the changes from the previous list happen. For this purpose, we have two options: Use native HTML elements and a set of special ARIA roles and attributes. Once implemented, changes to all child elements within the live region will become accessible to screen readers.
HTML elements
Unfortunately, there are not many native HTML elements for live regions (at least for now). One of them is the <output> element.
<output> used to display results. These could be mathematical calculations or the correct missing word in a sentence for grammar tests. Another less obvious use case is for pop-up notifications or toasts 🧇. These are alerts that slide in at the bottom or top of the screen and disappear after some time.
<button>Save</button>
 
 <div>
   <output>
diff --git a/en/articles/css-media-features-for-a11y/index.html b/en/articles/css-media-features-for-a11y/index.html
index 208d22f..29700c6 100644
--- a/en/articles/css-media-features-for-a11y/index.html
+++ b/en/articles/css-media-features-for-a11y/index.html
@@ -21,7 +21,7 @@
 			},
 			"datePublished": "2024-05-09T00:00:00.000Z",
 			"dateModified": "2024-09-05T00:00:00.000Z"
-		}
 
CSS media features to improve accessibility
  • CSS
  • Usability
 
 Updated: 
When people talk about accessibility and CSS, they often mean properties that affect the accessibility tree and assistive technologies such as screen readers and voice control software. But there's another ally in the battle for accessible interfaces — media features.
Media features are conditions for the @media CSS at-rule. They indicate specific characteristics of the device or browser. For example, screen orientation (orientation) or display mode (display-mode).
In this article, I'll talk about a few media features: prefers-reduced-motion, prefers-color-scheme, inverted-colors, forced-colors, ms-high-contrast, prefers-contrast, and prefers-reduced-transparency.
These media features track operating system settings which changed by users who aren't satisfied with the default behavior of the system. For example, people with disabilities and those who are uncomfortable with the default design. Real world examples:
  • Users prone to epileptic seizures turn off animation because it can trigger a photosensitive seizures
  • Some people with astigmatism choose a dark theme and reduce contrast to avoid eye strain.
Considering user preferences will make the site's interface more flexible and personalized. This will not only help improve its accessibility but can also increase conversion rates. It's always nice to use products that cares about your preferences.
Most customizations apply only to the operating system. Many of them, like animations and contrast levels, don't change website interfaces. It all depends on whether the developers have taken them into account. This is where media features come in handy.
You can also track user settings with JavaScript, but I don't want to make this post bigger. I'll just focus on CSS features.
System settings
Let's take a look at the settings which can be considered in web interfaces now or in the future.
Animation
Animation settings allow you to change the speed of animations or turn them off completely. These settings don't affect websites unless they contain specific CSS at-rule styles.
Users who may adjust animation settings include:
  • People with vestibular disorders or those prone to seizures
  • People with cognitive disabilities and neurodivergent users, particularly those with attention deficit disorder (ADD).
Most operating systems include the ″Reduce motion″ or ″Minimize animation″ setting to accommodate these users needs.
Color scheme
Users can also change the color scheme settings and select the colors that will dominate the system. These are either light or dark shades. The setting does not affect sites if they do not support color schemes.
The following categories of users utilize color scheme setting:
  • People with visual impairments. For example, a person with low vision, eye strain, and light sensitivity
  • Those with cognitive disabilities and neurodivergent folks. For instance, individuals with ADD
  • Everyone else due to aesthetic preferences, habits, or lighting conditions.
Color schemes can be selected in all popular operating systems. macOS and iOS have an additional automatic theme. If selected, it applies a light theme during the day and a dark theme at night.
Inverted colors
Inverted colors mode replaces system colors with their opposites, like a negative. It's a part of the filtered display mode category of settings.
Colors change not only in the system but also in browser tabs. So users might choose this mode instead of a dark theme. The screenshot shows how the inversion mode works. Yellow shades have turned blue, green has become magenta, and white has turned black.
Website interface in inverted colors mode.
Doka Guide with inverted colors on Windows 10.
Who uses inverted colors mode:
  • People with visual impairments. For example, individuals with glaucoma or eye strain
  • People with migraines and headaches
  • Other users due to personal preferences, habits, or lighting conditions.
Most operating systems have inverted colors setting. On iOS, there are even two types of inversion: Smart and classic. In smart invert mode, pictures and videos are not inverted, while in classic one, all content is inverted.
Forced colors
Forced colors mode limits the number of colors to improve text readability by changing the contrast between text and background. High-contrast colors are mainly used. This mode changes colors both in the system and on websites.
Who uses forced colors mode:
  • Users with visual impairments
  • People with migraines and headaches
  • People with photosensitive epilepsy
  • Users who need to reduce visual noise to improve concentration.
Currently, this mode can only be selected on Windows. On Windows 10 and earlier versions, it's called Windows high contrast mode (WHCM). On Windows 11, it's called contrast themes.
The high contrast mode has several pre-set color schemes:
  • High contrast black
  • High contrast white
  • High contrast one (1) and two (2).
The technology for replacing the color palette depends on the browser. It differs in Chromium-based browsers, Firefox (Quantum engine), Internet Explorer (Trident), and in older versions of Edge (EdgeHTML). For example, in Vivaldi (Chromium), the white background of the site becomes black, gray links and borders become bright yellow, and regular text becomes white instead of dark gray.
Section with podcast episodes on the main page.
″Web Standards″ website with the high contrast black mode in Vivaldi on Windows 10.
In Firefox, the originally white background will remain the same, gray links and borders will become bright blue, and regular text will be black instead of dark gray.
List of recent episodes of the ″Web Standards″ podcast.
A distinctive display of the high contrast black mode in Firefox on Windows 10.
You can change the default behavior in Firefox. The setting is located in the Language and Appearance section, specifically in the ″Colors″ subsection. Open the modal window with the ″Manage Colors…″ button and select the ″Use system colors″ checkbox.
On Windows 11, the set of contrast themes has changed: Aquatic, desert, dusk, and night sky have been added.
The podcast section from the ″Web Standards″ homepage with system colors. The white background has become black, links and borders are purple, and regular text is white instead of dark gray.
″Web Standards″ with the night sky mode in Vivaldi on Windows 11.
If the pre-set themes don't suit you, you can customize them yourself. This includes the option to reduce contrast.
Contrast
Users can separately increase or decrease the level of contrast in the system without changing the screen brightness.
The contrast settings is used by:
  • People with visual impairments, for example, those with glaucoma
  • People who have migraines and headaches
  • Those with old or low-quality displays
  • Others who need higher contrast due to lighting conditions.
macOS and iOS have the increased contrast mode. It increases the difference between shades of gray and makes element borders more distinct.
Increasing contrast affects the appearance of both the system and web interfaces. Unlike system windows, only the contrast level changes on websites.
Let's look at what happens to a modal window in macOS with default mode and with increased contrast mode. Both windows show an image of a screaming cat called ″cute-cat.jpeg″. The first window has no frame, and the background of the control panel with buttons and additional settings is light gray. The second window looks visually different from the first. It has a black frame, the background of the control panel has become white, and all buttons and other elements in the panel have separate black frames.
Comparison of windows in default mode and increased contrast mode.
Oddly enough, everything has become more contrast.
Transparency
Users can enable or disable background transparency. Those who increase contrast often choose an opaque background.
A transparent background can increase cognitive load and reduce text readability. Therefore, this setting is used by:
  • People with visual impairments. For example, those with astigmatism or low vision
  • Users with cognitive disabilities and neurodivergent people. For instance, dyslexic users or those with ADD
  • People with migraines and headaches.
Transparency can be precisely adjusted on Windows and in macOS. These settings not only affect the transparency in the system interface but also on websites and in browsers. This screenshot shows the navigation background of the first window is semi-transparent, while the second one has an opaque and solid background.
Comparison of two windows with transparency turned on and off.
This is how the transparency setting works on Windows 11.
A few words about media types
The @media at-rule in CSS has several media types. They describe the device on which the document is displayed.
  • all: All devices. It's set automatically if no other type is specified
  • screen: Devices with screens. For example, phones and laptops
  • print: Devices with preview and print functions. This includes printers
  • speech: Devices with speech synthesis. For example, screen readers and voice assistants.
The speech media type may be interesting from the point of view of accessibility. However, it is not currently supported by any browser. It used to be supported by the Opera browser on the Presto engine but support ceased after switching to Blink.
In the future, it may be useful for special styles for screen readers, such as to apply CSS properties for speech synthesis devices to some elements on a page.
Media features
Now we move on to media features that will help make web interfaces more accessible.
Some of them are not yet well supported by browsers. Things may change in the future with the development of CSS. In any case, it's useful to know about them.
prefers-reduced-motion
It tracks whether animation settings are selected to reduce its intensity. This is useful for any animation on the website. The animation can be slowed down or completely disabled.
Values for prefers-reduced-motion:
  • no-preference: Default animation settings
  • reduce: Modified animation settings.
Browser support for prefers-reduced-motion is relatively good: 97% (as of 2024).
In this code example we stop animation completely by using animation: none.
@media (prefers-reduced-motion: reduce) {
+		}
 
CSS media features to improve accessibility
  • CSS
  • Usability
 
 Updated: 
When people talk about accessibility and CSS, they often mean properties that affect the accessibility tree and assistive technologies such as screen readers and voice control software. But there's another ally in the battle for accessible interfaces — media features.
Media features are conditions for the @media CSS at-rule. They indicate specific characteristics of the device or browser. For example, screen orientation (orientation) or display mode (display-mode).
In this article, I'll talk about a few media features: prefers-reduced-motion, prefers-color-scheme, inverted-colors, forced-colors, ms-high-contrast, prefers-contrast, and prefers-reduced-transparency.
These media features track operating system settings which changed by users who aren't satisfied with the default behavior of the system. For example, people with disabilities and those who are uncomfortable with the default design. Real world examples:
  • Users prone to epileptic seizures turn off animation because it can trigger a photosensitive seizures
  • Some people with astigmatism choose a dark theme and reduce contrast to avoid eye strain.
Considering user preferences will make the site's interface more flexible and personalized. This will not only help improve its accessibility but can also increase conversion rates. It's always nice to use products that cares about your preferences.
Most customizations apply only to the operating system. Many of them, like animations and contrast levels, don't change website interfaces. It all depends on whether the developers have taken them into account. This is where media features come in handy.
You can also track user settings with JavaScript, but I don't want to make this post bigger. I'll just focus on CSS features.
System settings
Let's take a look at the settings which can be considered in web interfaces now or in the future.
Animation
Animation settings allow you to change the speed of animations or turn them off completely. These settings don't affect websites unless they contain specific CSS at-rule styles.
Users who may adjust animation settings include:
  • People with vestibular disorders or those prone to seizures
  • People with cognitive disabilities and neurodivergent users, particularly those with attention deficit disorder (ADD).
Most operating systems include the ″Reduce motion″ or ″Minimize animation″ setting to accommodate these users needs.
Color scheme
Users can also change the color scheme settings and select the colors that will dominate the system. These are either light or dark shades. The setting does not affect sites if they do not support color schemes.
The following categories of users utilize color scheme setting:
  • People with visual impairments. For example, a person with low vision, eye strain, and light sensitivity
  • Those with cognitive disabilities and neurodivergent folks. For instance, individuals with ADD
  • Everyone else due to aesthetic preferences, habits, or lighting conditions.
Color schemes can be selected in all popular operating systems. macOS and iOS have an additional automatic theme. If selected, it applies a light theme during the day and a dark theme at night.
Inverted colors
Inverted colors mode replaces system colors with their opposites, like a negative. It's a part of the filtered display mode category of settings.
Colors change not only in the system but also in browser tabs. So users might choose this mode instead of a dark theme. The screenshot shows how the inversion mode works. Yellow shades have turned blue, green has become magenta, and white has turned black.
Website interface in inverted colors mode.
Doka Guide with inverted colors on Windows 10.
Who uses inverted colors mode:
  • People with visual impairments. For example, individuals with glaucoma or eye strain
  • People with migraines and headaches
  • Other users due to personal preferences, habits, or lighting conditions.
Most operating systems have inverted colors setting. On iOS, there are even two types of inversion: Smart and classic. In smart invert mode, pictures and videos are not inverted, while in classic one, all content is inverted.
Forced colors
Forced colors mode limits the number of colors to improve text readability by changing the contrast between text and background. High-contrast colors are mainly used. This mode changes colors both in the system and on websites.
Who uses forced colors mode:
  • Users with visual impairments
  • People with migraines and headaches
  • People with photosensitive epilepsy
  • Users who need to reduce visual noise to improve concentration.
Currently, this mode can only be selected on Windows. On Windows 10 and earlier versions, it's called Windows high contrast mode (WHCM). On Windows 11, it's called contrast themes.
The high contrast mode has several pre-set color schemes:
  • High contrast black
  • High contrast white
  • High contrast one (1) and two (2).
The technology for replacing the color palette depends on the browser. It differs in Chromium-based browsers, Firefox (Quantum engine), Internet Explorer (Trident), and in older versions of Edge (EdgeHTML). For example, in Vivaldi (Chromium), the white background of the site becomes black, gray links and borders become bright yellow, and regular text becomes white instead of dark gray.
Section with podcast episodes on the main page.
″Web Standards″ website with the high contrast black mode in Vivaldi on Windows 10.
In Firefox, the originally white background will remain the same, gray links and borders will become bright blue, and regular text will be black instead of dark gray.
List of recent episodes of the ″Web Standards″ podcast.
A distinctive display of the high contrast black mode in Firefox on Windows 10.
You can change the default behavior in Firefox. The setting is located in the Language and Appearance section, specifically in the ″Colors″ subsection. Open the modal window with the ″Manage Colors…″ button and select the ″Use system colors″ checkbox.
On Windows 11, the set of contrast themes has changed: Aquatic, desert, dusk, and night sky have been added.
The podcast section from the ″Web Standards″ homepage with system colors. The white background has become black, links and borders are purple, and regular text is white instead of dark gray.
″Web Standards″ with the night sky mode in Vivaldi on Windows 11.
If the pre-set themes don't suit you, you can customize them yourself. This includes the option to reduce contrast.
Contrast
Users can separately increase or decrease the level of contrast in the system without changing the screen brightness.
The contrast settings is used by:
  • People with visual impairments, for example, those with glaucoma
  • People who have migraines and headaches
  • Those with old or low-quality displays
  • Others who need higher contrast due to lighting conditions.
macOS and iOS have the increased contrast mode. It increases the difference between shades of gray and makes element borders more distinct.
Increasing contrast affects the appearance of both the system and web interfaces. Unlike system windows, only the contrast level changes on websites.
Let's look at what happens to a modal window in macOS with default mode and with increased contrast mode. Both windows show an image of a screaming cat called ″cute-cat.jpeg″. The first window has no frame, and the background of the control panel with buttons and additional settings is light gray. The second window looks visually different from the first. It has a black frame, the background of the control panel has become white, and all buttons and other elements in the panel have separate black frames.
Comparison of windows in default mode and increased contrast mode.
Oddly enough, everything has become more contrast.
Transparency
Users can enable or disable background transparency. Those who increase contrast often choose an opaque background.
A transparent background can increase cognitive load and reduce text readability. Therefore, this setting is used by:
  • People with visual impairments. For example, those with astigmatism or low vision
  • Users with cognitive disabilities and neurodivergent people. For instance, dyslexic users or those with ADD
  • People with migraines and headaches.
Transparency can be precisely adjusted on Windows and in macOS. These settings not only affect the transparency in the system interface but also on websites and in browsers. This screenshot shows the navigation background of the first window is semi-transparent, while the second one has an opaque and solid background.
Comparison of two windows with transparency turned on and off.
This is how the transparency setting works on Windows 11.
A few words about media types
The @media at-rule in CSS has several media types. They describe the device on which the document is displayed.
  • all: All devices. It's set automatically if no other type is specified
  • screen: Devices with screens. For example, phones and laptops
  • print: Devices with preview and print functions. This includes printers
  • speech: Devices with speech synthesis. For example, screen readers and voice assistants.
The speech media type may be interesting from the point of view of accessibility. However, it is not currently supported by any browser. It used to be supported by the Opera browser on the Presto engine but support ceased after switching to Blink.
In the future, it may be useful for special styles for screen readers, such as to apply CSS properties for speech synthesis devices to some elements on a page.
Media features
Now we move on to media features that will help make web interfaces more accessible.
Some of them are not yet well supported by browsers. Things may change in the future with the development of CSS. In any case, it's useful to know about them.
prefers-reduced-motion
It tracks whether animation settings are selected to reduce its intensity. This is useful for any animation on the website. The animation can be slowed down or completely disabled.
Values for prefers-reduced-motion:
  • no-preference: Default animation settings
  • reduce: Modified animation settings.
Browser support for prefers-reduced-motion is relatively good: 97% (as of 2024).
In this code example we stop animation completely by using animation: none.
@media (prefers-reduced-motion: reduce) {
   .danger-animation {
     animation: none;
   }
diff --git a/en/articles/how-to-protect-users-with-epilepsy-and-vd/index.html b/en/articles/how-to-protect-users-with-epilepsy-and-vd/index.html
index 352037e..eb6cb97 100644
--- a/en/articles/how-to-protect-users-with-epilepsy-and-vd/index.html
+++ b/en/articles/how-to-protect-users-with-epilepsy-and-vd/index.html
@@ -21,7 +21,7 @@
 			},
 			"datePublished": "2024-05-16T00:00:00.000Z",
 			"dateModified": "2024-08-26T00:00:00.000Z"
-		}
 
Thinking about users with seizures and vestibular conditions
  • Design
  • Animation
  • CSS
 
 Updated: 
Accessibility helps users not only use interfaces without trouble but also avoid feeling physically unwell. Here, I want to discuss what accessibility means for people with seizures and vestibular conditions.
Vestibular conditions can appear spontaneously. For example, they may occur due to side effects from medications, head injuries, and even hot weather. A similar situation applies to seizures. While we are somewhat prepared for screen reader users, we cannot predict what will make a person feel unwell. Therefore, it's crucial to avoid creating barriers from the start.
Let's start with the definitions of vestibular disorders, seizures, and epilepsy.
Vestibular disorders
It's likely that you have experienced motion sickness, dizziness, or nausea at least once in your life. The reason could be lack of sleep, a cold, a long car journey, or various other factors.
Vestibular disorders are related to the inner ear and the part of the brain that controls balance and eye movement.
This is a large group of medical conditions, including head injuries, vestibular migraine or migraine with aura, and brain tumors. They often have similar symptoms:
  • dizziness (vertigo)
  • nausea
  • blurred vision
  • eye strain
  • headaches
  • trouble concentrating
  • confusion.
One of the triggers can be inaccessible user interfaces. Facundo Corradini, in an article on A List Apart, described how he lay in bed for hours with severe vertigo after encountering parallax scrolling effects.
There are indeed many such users. Worldwide, about 15% of people experience migraines (statistics as of 2023).
Seizures and epilepsy
A seizure is uncontrolled increased or synchronized activity of neurons in the brain. Its effects can include dizziness, paralysis, temporary failure of internal organs, loss of consciousness, confusion, partial memory loss, and outbreaks of fear and anxiety.
Seizures can occur on their own or be part of a disability. If they recur frequently, more than three times, they are considered epilepsy. Globally, about 6,5% of people have epilepsy (statistics as of 2019).
Seizures can be influenced not only by internal factors but also by external ones, such as light or sounds. Seizures triggered by light, sounds, and even reading are called reflex seizures. When there are many such seizures, a person has reflex epilepsy (RE).
Reflex epilepsy comes in several types. I am going to focus only on photosensitive epilepsy (PSE). It's triggered by intense flickering light or movement. PSE occurs in 3–5% of all people with epilepsy. The condition manifest between the ages of seven (7) and nineteen (19), but people can experience it in their adult life as well.
Content that flashes, flickers, or blinks can lead to an epileptic seizure. These triggers seriously increase electrical activity in neurons.
Problematic content
Several elements in web interfaces can potentially cause seizures or other adverse physical reactions:
  • media content such as videos and GIFs
  • animated scrolling that lasts longer than one quarter (1/4) second or 15 milliseconds
  • web canvas animations
  • graphics with contrasting stripes, squares, spirals, and concentric circles
  • SVG, CSS, and JavaScript animations. E.g., moving images next to text or parallax scrolling effects where foreground and background scroll simultaneously in different directions
    high contrast elements and interfaces.
I have personally experienced eye strain and nausea due to such visual elements. In my case, it was caused by the splash screen in WebStorm 2021.1, which was just a static image. I'm grateful to the JetBrains team for listening to feedback and reducing the saturation of the images.
For more examples of problematic interfaces, I recommend reading ″Your Interactive Makes Me Sick″ by Eileen Webb. It provides valuable insights into this issue, though I hope your vestibular system handles the challenge better than mine did.
You don't even need an image or video to cause harm. A <div> element set to change colour and luminosity at high frequency, easily done via JavaScript, can cause real harm. And, flickering can occur everywhere. For example, ″spinners″ commonly used to display while pages load can easily ″flicker″ while spinning.
MDN.
How to protect users?
It's crucial to note that directly involving people with epilepsy and vestibular disorders in testing can be potentially dangerous. Therefore, the most responsible approach is to be proactive and implement expert recommendations.
To ensure we don't unintentionally harm users, consider the guidelines below.
Monitor flash frequency. The rapid appearance of bright light is called flashes. They can be either general or red. Flashes are common in videos and animations.
A general flash is a rapid increase in brightness by 10% or more, followed by a decrease to 0,8% or less.
A red flash is a pair of opposite transitions involving a saturated red color.
Besides flashes, there are also blinks. Blinking content switches between two states. It's usually used to draw attention to specific elements on a page.
The frequency of general and red flashes, as well as blinks, should not exceed three (3) times per second or three (3) hertz (Hz). This is the minimum accessibility requirement for people with photosensitive epilepsy.
The best solution to the problem of flashes and blinks is to avoid them altogether. Another approach is the small safe area technique, where you reduce the size of the video or the part of the page with potentially dangerous animation. The area should occupy less than 10% of the central field of vision or less than 25% of the screen size. This is because the central part of the eye consists of a large number of sensors that more actively transmit signals to the visual cortex and can overload neurons.
Reducing the area of flashes and blinks is not the best solution, as users may access the site from a mobile device and hold it too close to their eyes.
Regarding blinks, if they are short-lived and stop automatically, that's generally acceptable.
You can check videos and animations using the free Photosensitive Epilepsy Analysis Tool (PEAT). However, it's only suitable for non-commercial purposes. For commercial use, there's the paid Harding Test.
Turn off animation. You can disable animation if it's not a key functionality. The prefers-reduced-motion media feature is useful for this. It checks the ″Reduce Motion″ setting in macOS or the ″Show Animations″ setting in Windows. You can see how this media feature works in W3C demo.
There are no absolute values for speed, smoothness, and other animation properties. So you can rely on the experience of other developers or ask for advice from users.
Option one (1): Only prefers-reduced-motion (suggested by Val Head).
@media (prefers-reduced-motion: reduce) {
+		}
 
Thinking about users with seizures and vestibular conditions
  • Design
  • Animation
  • CSS
 
 Updated: 
Accessibility helps users not only use interfaces without trouble but also avoid feeling physically unwell. Here, I want to discuss what accessibility means for people with seizures and vestibular conditions.
Vestibular conditions can appear spontaneously. For example, they may occur due to side effects from medications, head injuries, and even hot weather. A similar situation applies to seizures. While we are somewhat prepared for screen reader users, we cannot predict what will make a person feel unwell. Therefore, it's crucial to avoid creating barriers from the start.
Let's start with the definitions of vestibular disorders, seizures, and epilepsy.
Vestibular disorders
It's likely that you have experienced motion sickness, dizziness, or nausea at least once in your life. The reason could be lack of sleep, a cold, a long car journey, or various other factors.
Vestibular disorders are related to the inner ear and the part of the brain that controls balance and eye movement.
This is a large group of medical conditions, including head injuries, vestibular migraine or migraine with aura, and brain tumors. They often have similar symptoms:
  • dizziness (vertigo)
  • nausea
  • blurred vision
  • eye strain
  • headaches
  • trouble concentrating
  • confusion.
One of the triggers can be inaccessible user interfaces. Facundo Corradini, in an article on A List Apart, described how he lay in bed for hours with severe vertigo after encountering parallax scrolling effects.
There are indeed many such users. Worldwide, about 15% of people experience migraines (statistics as of 2023).
Seizures and epilepsy
A seizure is uncontrolled increased or synchronized activity of neurons in the brain. Its effects can include dizziness, paralysis, temporary failure of internal organs, loss of consciousness, confusion, partial memory loss, and outbreaks of fear and anxiety.
Seizures can occur on their own or be part of a disability. If they recur frequently, more than three times, they are considered epilepsy. Globally, about 6,5% of people have epilepsy (statistics as of 2019).
Seizures can be influenced not only by internal factors but also by external ones, such as light or sounds. Seizures triggered by light, sounds, and even reading are called reflex seizures. When there are many such seizures, a person has reflex epilepsy (RE).
Reflex epilepsy comes in several types. I am going to focus only on photosensitive epilepsy (PSE). It's triggered by intense flickering light or movement. PSE occurs in 3–5% of all people with epilepsy. The condition manifest between the ages of seven (7) and nineteen (19), but people can experience it in their adult life as well.
Content that flashes, flickers, or blinks can lead to an epileptic seizure. These triggers seriously increase electrical activity in neurons.
Problematic content
Several elements in web interfaces can potentially cause seizures or other adverse physical reactions:
  • media content such as videos and GIFs
  • animated scrolling that lasts longer than one quarter (1/4) second or 15 milliseconds
  • web canvas animations
  • graphics with contrasting stripes, squares, spirals, and concentric circles
  • SVG, CSS, and JavaScript animations. E.g., moving images next to text or parallax scrolling effects where foreground and background scroll simultaneously in different directions
    high contrast elements and interfaces.
I have personally experienced eye strain and nausea due to such visual elements. In my case, it was caused by the splash screen in WebStorm 2021.1, which was just a static image. I'm grateful to the JetBrains team for listening to feedback and reducing the saturation of the images.
For more examples of problematic interfaces, I recommend reading ″Your Interactive Makes Me Sick″ by Eileen Webb. It provides valuable insights into this issue, though I hope your vestibular system handles the challenge better than mine did.
You don't even need an image or video to cause harm. A <div> element set to change colour and luminosity at high frequency, easily done via JavaScript, can cause real harm. And, flickering can occur everywhere. For example, ″spinners″ commonly used to display while pages load can easily ″flicker″ while spinning.
MDN.
How to protect users?
It's crucial to note that directly involving people with epilepsy and vestibular disorders in testing can be potentially dangerous. Therefore, the most responsible approach is to be proactive and implement expert recommendations.
To ensure we don't unintentionally harm users, consider the guidelines below.
Monitor flash frequency. The rapid appearance of bright light is called flashes. They can be either general or red. Flashes are common in videos and animations.
A general flash is a rapid increase in brightness by 10% or more, followed by a decrease to 0,8% or less.
A red flash is a pair of opposite transitions involving a saturated red color.
Besides flashes, there are also blinks. Blinking content switches between two states. It's usually used to draw attention to specific elements on a page.
The frequency of general and red flashes, as well as blinks, should not exceed three (3) times per second or three (3) hertz (Hz). This is the minimum accessibility requirement for people with photosensitive epilepsy.
The best solution to the problem of flashes and blinks is to avoid them altogether. Another approach is the small safe area technique, where you reduce the size of the video or the part of the page with potentially dangerous animation. The area should occupy less than 10% of the central field of vision or less than 25% of the screen size. This is because the central part of the eye consists of a large number of sensors that more actively transmit signals to the visual cortex and can overload neurons.
Reducing the area of flashes and blinks is not the best solution, as users may access the site from a mobile device and hold it too close to their eyes.
Regarding blinks, if they are short-lived and stop automatically, that's generally acceptable.
You can check videos and animations using the free Photosensitive Epilepsy Analysis Tool (PEAT). However, it's only suitable for non-commercial purposes. For commercial use, there's the paid Harding Test.
Turn off animation. You can disable animation if it's not a key functionality. The prefers-reduced-motion media feature is useful for this. It checks the ″Reduce Motion″ setting in macOS or the ″Show Animations″ setting in Windows. You can see how this media feature works in W3C demo.
There are no absolute values for speed, smoothness, and other animation properties. So you can rely on the experience of other developers or ask for advice from users.
Option one (1): Only prefers-reduced-motion (suggested by Val Head).
@media (prefers-reduced-motion: reduce) {
   *:not(.safe-animation),
   *:not(.safe-animation)::before,
   *:not(.safe-animation)::after {
diff --git a/en/articles/index.html b/en/articles/index.html
index e59f183..4a58748 100644
--- a/en/articles/index.html
+++ b/en/articles/index.html
@@ -1 +1 @@
-All articles — Blog on Digital Accessibility
 
All articles
Role attribute with multiple values
In what cases may be necessary to set multiple values for a role attribute, and how browsers and screen readers deal with this.
  • ARIA
  • HTML
 
What you need to know about ARIA live regions
If you're looking to make dynamic page content accessible, WAI-ARIA provides a solution. Previously, assistive technologies struggled with these elements, but now they can be properly handled using ARIA live regions.
  • ARIA
  • HTML
  • Screen readers
 
CSS media features to improve accessibility
Learn how to incorporate user-defined settings into web interfaces. This article explores media features that track various user preferences, including animation, contrast, transparency, inversion, color schemes and forced color modes.
  • CSS
  • Usability
 
Understanding skip links
How to help users to skip large chank of a page content, whose these users are, and how to implement it on your website.
  • Patterns
  • HTML
  • CSS
 
 Tatiana Fokina, 2021–2024
Build on 11ty, icons by Lucide Find an issue? Let me know on GitHub

\ No newline at end of file
+All articles — Blog on Digital Accessibility
 
All articles
Role attribute with multiple values
In what cases may be necessary to set multiple values for a role attribute, and how browsers and screen readers deal with this.
  • ARIA
  • HTML
 
What you need to know about ARIA live regions
If you're looking to make dynamic page content accessible, WAI-ARIA provides a solution. Previously, assistive technologies struggled with these elements, but now they can be properly handled using ARIA live regions.
  • ARIA
  • HTML
  • Screen readers
 
CSS media features to improve accessibility
Learn how to incorporate user-defined settings into web interfaces. This article explores media features that track various user preferences, including animation, contrast, transparency, inversion, color schemes and forced color modes.
  • CSS
  • Usability
 
Understanding skip links
How to help users to skip large chank of a page content, whose these users are, and how to implement it on your website.
  • Patterns
  • HTML
  • CSS
 
 Tatiana Fokina, 2021–2024
Build on 11ty, icons by Lucide Find an issue? Let me know on GitHub

\ No newline at end of file
diff --git a/en/articles/understanding-a-skip-link/index.html b/en/articles/understanding-a-skip-link/index.html
index 665395c..0ede532 100644
--- a/en/articles/understanding-a-skip-link/index.html
+++ b/en/articles/understanding-a-skip-link/index.html
@@ -21,7 +21,7 @@
 			},
 			"datePublished": "2024-05-05T00:00:00.000Z",
 			"dateModified": "2024-06-13T00:00:00.000Z"
-		}
 
Understanding skip links
  • Patterns
  • HTML
  • CSS
 
 Updated: 
There are many small but useful patterns available on the web. One of them is a content skip link or skip link. This is a hyperlink that leads to the main content of a page and helps to skip through lengthy, repetitive content. Its main purpose is to save users' time.
What kind of content is considered bulky? A navigation menu with a logo and a lot of links, a complex table, letter indexes, and lists with chapters or technical specifications. Most often, the skip link is useful for skipping site navigation from a header.
Exceptions are a footer menu and a brief header navigation, which consists of a couple of links and a site logo. In the case of footers, you can return to the top of a page using keyboard keys, gestures, and other in-built browser features. So, a brief navigation won't take up much time for users.
In theory, everything is simple. In practice, it's a bit more complicated. Let's learn step by steps.
Theory
What WCAG 2.2 says
In the accessibility guidelines, there are two criteria related to skip links.
  • Criterion 2.1.1 Keyboard (A). All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes.
  • Criterion 2.4.1 Block Skipping (A). A mechanism is available to bypass blocks of content that are repeated on multiple web pages.
Mechanics for skipping blocks
There are two mechanics for skipping content on a web page:
  • Landmark navigation (landmarks)
  • Skip link.
The first method is available for screen reader users. Landmarks are created using semantic tags, thanks to ARIA. The second mechanic has a larger audience. It's not only for users with visual impairments.
You can find advice that the skip link isn't necessary for websites with a good layouts. This isn't quite true. Not all screen reader users know about shortcuts for landmarks. Other keyboard users don't have this option at all. Also, the more options for navigation, the better.
Who needs it
In short, anyone who consistently navigates through pages and can't skip content quickly. In a nutshell, there are four (4) categories of users.
  • Screen reader users, who navigate through websites with a keyboard and mobile versions of websites by taps and swipes
  • Users with motor impairments who use a keyboard, remote computer buttons, and other switch devices
  • Any other keyboard users. They may be of an advanced level or have temporarily broken devices, such as a computer mouse, etc.
  • Screen magnifier users who use the keyboard to navigate.
Imagine that you're using a keyboard for navigation and open any online shopping platform. You found the product you wanted, navigated to it, and found yourself on the top of the page. About forty (40) tabs later, you can finally find out more about your perfect backpack. With the skip link, you would be in the right part of a page in one tab and not fall asleep on the way 😴.
List of requirements
  • Located in tab order first
  • Leads directly to the main content and sets the focus on it. It's more effective if the page has one main area
  • It can be located in the main part of the page. In this case, it skips the necessary block and leads to the beginning of the next part of a web page
  • It has a clear name and a good description of where it leads
  • It can always be visible, or it can appear when a person uses a keyboard. In both cases, it meets WCAG criteria
  • You can add more than one of the skip links. For example, one leads to the main content, and the second to the search bar. It's better don't overdo the number. Otherwise, there is no point in the skip-link pattern
  • It shouldn't interfere with mouse users. This is a controversial requirement, but it has a grain of truth. If such a link is always visible, it may confuse mouse users. They aren't familiar with this pattern, and don't need another way to scroll to the main content.
Practice
You need to support keyboard navigation from the start. In other cases, the skip link is useless by default.
Marking up the page
Before we move on to HTML and CSS, I want to say a couple of words about skip link names. On English-language websites, ″Skip to main content″ or ″Skip to content″ is most often used. There are a few more options:
  • Skip navigation
  • Skip main navigation
  • Skip navigation links.
Finally, let's talk about HTML.
The practical implementation of the skip link is an anchor link. It's better to add it at start of a page, before other HTML elements. The best parts of HTML code for that reason are <header> if it's the first element on the page or <body>. I'm going to use the link as the first child element for the header one.
<header>
+		}
 
Understanding skip links
  • Patterns
  • HTML
  • CSS
 
 Updated: 
There are many small but useful patterns available on the web. One of them is a content skip link or skip link. This is a hyperlink that leads to the main content of a page and helps to skip through lengthy, repetitive content. Its main purpose is to save users' time.
What kind of content is considered bulky? A navigation menu with a logo and a lot of links, a complex table, letter indexes, and lists with chapters or technical specifications. Most often, the skip link is useful for skipping site navigation from a header.
Exceptions are a footer menu and a brief header navigation, which consists of a couple of links and a site logo. In the case of footers, you can return to the top of a page using keyboard keys, gestures, and other in-built browser features. So, a brief navigation won't take up much time for users.
In theory, everything is simple. In practice, it's a bit more complicated. Let's learn step by steps.
Theory
What WCAG 2.2 says
In the accessibility guidelines, there are two criteria related to skip links.
  • Criterion 2.1.1 Keyboard (A). All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes.
  • Criterion 2.4.1 Block Skipping (A). A mechanism is available to bypass blocks of content that are repeated on multiple web pages.
Mechanics for skipping blocks
There are two mechanics for skipping content on a web page:
  • Landmark navigation (landmarks)
  • Skip link.
The first method is available for screen reader users. Landmarks are created using semantic tags, thanks to ARIA. The second mechanic has a larger audience. It's not only for users with visual impairments.
You can find advice that the skip link isn't necessary for websites with a good layouts. This isn't quite true. Not all screen reader users know about shortcuts for landmarks. Other keyboard users don't have this option at all. Also, the more options for navigation, the better.
Who needs it
In short, anyone who consistently navigates through pages and can't skip content quickly. In a nutshell, there are four (4) categories of users.
  • Screen reader users, who navigate through websites with a keyboard and mobile versions of websites by taps and swipes
  • Users with motor impairments who use a keyboard, remote computer buttons, and other switch devices
  • Any other keyboard users. They may be of an advanced level or have temporarily broken devices, such as a computer mouse, etc.
  • Screen magnifier users who use the keyboard to navigate.
Imagine that you're using a keyboard for navigation and open any online shopping platform. You found the product you wanted, navigated to it, and found yourself on the top of the page. About forty (40) tabs later, you can finally find out more about your perfect backpack. With the skip link, you would be in the right part of a page in one tab and not fall asleep on the way 😴.
List of requirements
  • Located in tab order first
  • Leads directly to the main content and sets the focus on it. It's more effective if the page has one main area
  • It can be located in the main part of the page. In this case, it skips the necessary block and leads to the beginning of the next part of a web page
  • It has a clear name and a good description of where it leads
  • It can always be visible, or it can appear when a person uses a keyboard. In both cases, it meets WCAG criteria
  • You can add more than one of the skip links. For example, one leads to the main content, and the second to the search bar. It's better don't overdo the number. Otherwise, there is no point in the skip-link pattern
  • It shouldn't interfere with mouse users. This is a controversial requirement, but it has a grain of truth. If such a link is always visible, it may confuse mouse users. They aren't familiar with this pattern, and don't need another way to scroll to the main content.
Practice
You need to support keyboard navigation from the start. In other cases, the skip link is useless by default.
Marking up the page
Before we move on to HTML and CSS, I want to say a couple of words about skip link names. On English-language websites, ″Skip to main content″ or ″Skip to content″ is most often used. There are a few more options:
  • Skip navigation
  • Skip main navigation
  • Skip navigation links.
Finally, let's talk about HTML.
The practical implementation of the skip link is an anchor link. It's better to add it at start of a page, before other HTML elements. The best parts of HTML code for that reason are <header> if it's the first element on the page or <body>. I'm going to use the link as the first child element for the header one.
<header>
   <a href="#main-content" class="skip-link">
     Skip to content
   </a>
diff --git a/en/feed.xml b/en/feed.xml
index d9a8c0e..a6572a3 100644
--- a/en/feed.xml
+++ b/en/feed.xml
@@ -1 +1 @@
-Blog on Digital AccessibilityPractical advice on digital accessibility for frontend developers, QA testers and designers. Here you'll learn about methods of creating accessible and user-friendly interfaces, standards, assistive technologies and laws.https://a11y-blog.dev/Mon, 03 Jun 2024 00:00:00 GMTRole attribute with multiple valuesIn what cases may be necessary to set multiple values for a role attribute, and how browsers and screen readers deal with this.https://a11y-blog.dev/en/articles/aria-attribute-role-with-multiple-values/Mon, 03 Jun 2024 00:00:00 GMThttps://a11y-blog.dev/en/articles/aria-attribute-role-with-multiple-values/Thinking about users with seizures and vestibular conditionsWhat if the user gets motion sickness because of a website? What if he or she has an epileptic seizure? Let's look at what interfaces for users with seizures and vestibular conditions should look like.https://a11y-blog.dev/en/articles/how-to-protect-users-with-epilepsy-and-vd/Thu, 16 May 2024 00:00:00 GMThttps://a11y-blog.dev/en/articles/how-to-protect-users-with-epilepsy-and-vd/What you need to know about ARIA live regionsIf you're looking to make dynamic page content accessible, WAI-ARIA provides a solution. Previously, assistive technologies struggled with these elements, but now they can be properly handled using ARIA live regions.https://a11y-blog.dev/en/articles/aria-live-regions/Sat, 11 May 2024 00:00:00 GMThttps://a11y-blog.dev/en/articles/aria-live-regions/CSS media features to improve accessibilityLearn how to incorporate user-defined settings into web interfaces. This article explores media features that track various user preferences, including animation, contrast, transparency, inversion, color schemes and forced color modes.https://a11y-blog.dev/en/articles/css-media-features-for-a11y/Thu, 09 May 2024 00:00:00 GMThttps://a11y-blog.dev/en/articles/css-media-features-for-a11y/Understanding skip linksHow to help users to skip large chank of a page content, whose these users are, and how to implement it on your website.https://a11y-blog.dev/en/articles/understanding-a-skip-link/Sun, 05 May 2024 00:00:00 GMThttps://a11y-blog.dev/en/articles/understanding-a-skip-link/
\ No newline at end of file
+Blog on Digital AccessibilityPractical advice on digital accessibility for frontend developers, QA testers and designers. Here you'll learn about methods of creating accessible and user-friendly interfaces, standards, assistive technologies and laws.https://a11y-blog.dev/Mon, 03 Jun 2024 00:00:00 GMTRole attribute with multiple valuesIn what cases may be necessary to set multiple values for a role attribute, and how browsers and screen readers deal with this.https://a11y-blog.dev/en/articles/aria-attribute-role-with-multiple-values/Mon, 03 Jun 2024 00:00:00 GMThttps://a11y-blog.dev/en/articles/aria-attribute-role-with-multiple-values/Thinking about users with seizures and vestibular conditionsWhat if the user gets motion sickness because of a website? What if he or she has an epileptic seizure? Let's look at what interfaces for users with seizures and vestibular conditions should look like.https://a11y-blog.dev/en/articles/how-to-protect-users-with-epilepsy-and-vd/Thu, 16 May 2024 00:00:00 GMThttps://a11y-blog.dev/en/articles/how-to-protect-users-with-epilepsy-and-vd/What you need to know about ARIA live regionsIf you're looking to make dynamic page content accessible, WAI-ARIA provides a solution. Previously, assistive technologies struggled with these elements, but now they can be properly handled using ARIA live regions.https://a11y-blog.dev/en/articles/aria-live-regions/Sat, 11 May 2024 00:00:00 GMThttps://a11y-blog.dev/en/articles/aria-live-regions/CSS media features to improve accessibilityLearn how to incorporate user-defined settings into web interfaces. This article explores media features that track various user preferences, including animation, contrast, transparency, inversion, color schemes and forced color modes.https://a11y-blog.dev/en/articles/css-media-features-for-a11y/Thu, 09 May 2024 00:00:00 GMThttps://a11y-blog.dev/en/articles/css-media-features-for-a11y/Understanding skip linksHow to help users to skip large chank of a page content, whose these users are, and how to implement it on your website.https://a11y-blog.dev/en/articles/understanding-a-skip-link/Sun, 05 May 2024 00:00:00 GMThttps://a11y-blog.dev/en/articles/understanding-a-skip-link/
diff --git a/en/index.html b/en/index.html
index 74c1178..95a10af 100644
--- a/en/index.html
+++ b/en/index.html
@@ -1 +1 @@
-Blog on Digital Accessibility
 
Articles on accessibility
Hi, my name is Tatiana Fokina, or just Tanya for short. Who am I? I am a web accessibility specialist and enthusiast who likes developing user-friendly interfaces and discussing digital accessibility with others (sometimes in the middle of the night).
In this blog, I share practical tips and hacks, useful links, my thoughts, and interesting findings about accessible code, design, and much more ✨
If you have any questions about my articles or accessibility, feel free to ask me on LinkedIn and Twitter.
Resent articles
Role attribute with multiple values
In what cases may be necessary to set multiple values for a role attribute, and how browsers and screen readers deal with this.
  • ARIA
  • HTML
 
What you need to know about ARIA live regions
If you're looking to make dynamic page content accessible, WAI-ARIA provides a solution. Previously, assistive technologies struggled with these elements, but now they can be properly handled using ARIA live regions.
  • ARIA
  • HTML
  • Screen readers
 
All articles
 Tatiana Fokina, 2021–2024
Build on 11ty, icons by Lucide Find an issue? Let me know on GitHub

\ No newline at end of file
+Blog on Digital Accessibility
 
Articles on accessibility
Hi, my name is Tatiana Fokina, or just Tanya for short. Who am I? I am a web accessibility specialist and enthusiast who likes developing user-friendly interfaces and discussing digital accessibility with others (sometimes in the middle of the night).
In this blog, I share practical tips and hacks, useful links, my thoughts, and interesting findings about accessible code, design, and much more ✨
If you have any questions about my articles or accessibility, feel free to ask me on LinkedIn and Twitter.
Resent articles
Role attribute with multiple values
In what cases may be necessary to set multiple values for a role attribute, and how browsers and screen readers deal with this.
  • ARIA
  • HTML
 
What you need to know about ARIA live regions
If you're looking to make dynamic page content accessible, WAI-ARIA provides a solution. Previously, assistive technologies struggled with these elements, but now they can be properly handled using ARIA live regions.
  • ARIA
  • HTML
  • Screen readers
 
All articles
 Tatiana Fokina, 2021–2024
Build on 11ty, icons by Lucide Find an issue? Let me know on GitHub

\ No newline at end of file
diff --git a/manifest.json b/manifest.json
index 7cee7b5..cf12e39 100644
--- a/manifest.json
+++ b/manifest.json
@@ -21,4 +21,4 @@
 	"theme_color": "#ffffff",
 	"background_color": "#ffffff",
 	"display": "browser"
-}
\ No newline at end of file
+}
diff --git a/robots.txt b/robots.txt
index c1c6f6f..4070eaf 100644
--- a/robots.txt
+++ b/robots.txt
@@ -1,4 +1,4 @@
 User-agent: *
 Allow: /
 
-Sitemap: https://a11y-blog.dev/sitemap.xml
\ No newline at end of file
+Sitemap: https://a11y-blog.dev/sitemap.xml
diff --git a/ru/404.html b/ru/404.html
index 22053b1..902aba2 100644
--- a/ru/404.html
+++ b/ru/404.html
@@ -1 +1 @@
-Страница не найдена — Блог о цифровой доступности
 
Страница не найдена
Скорее всего, такой страницы не существует.
Вернуться на главную страницу
 Татьяна Фокина, 2021–2024
Разработано на 11ty, иконки с Lucide Нашли ошибку? Поделитесь ей на GitHub

\ No newline at end of file
+Страница не найдена — Блог о цифровой доступности
 
Страница не найдена
Скорее всего, такой страницы не существует.
Вернуться на главную страницу
 Татьяна Фокина, 2021–2024
Разработано на 11ty, иконки с Lucide Нашли ошибку? Поделитесь ей на GitHub

\ No newline at end of file
diff --git a/ru/articles/aria-attribute-role-with-multiple-values/index.html b/ru/articles/aria-attribute-role-with-multiple-values/index.html
index 312ae67..f4dfa5b 100644
--- a/ru/articles/aria-attribute-role-with-multiple-values/index.html
+++ b/ru/articles/aria-attribute-role-with-multiple-values/index.html
@@ -21,7 +21,7 @@
 			},
 			"datePublished": "2022-01-24T00:00:00.000Z",
 			"dateModified": "2024-06-28T00:00:00.000Z"
-		}
 
role с несколькими значениями
  • ARIA
 
 Обновлено: 
Недавно случайно узнала, что ARIA-атрибут role может содержать больше одного значения. И это очень неожиданно, по крайней мере для меня.
Этот пост написала из исследовательского интереса, так что в нём нет большого количества полезных практических советов. Что-то даже лучше не применять на практике.
Небольшая справка о роли элемента
Роль содержит информацию о функциях элемента и как с ним можно взаимодействовать. К примеру, о <button> скринридер объявит, что это кнопка, а также сможет на неё нажать.
У элементов может быть либо встроенная роль, либо явно заданная в атрибуте role.
Есть много категорий и видов ролей, и существуют чёткие правила их явного использования. Например, нельзя менять роли при взаимодействии с элементом или задавать абстрактные (landmark, section, widget и другие). Также есть роли, которые предполагают вложенные элементы. Например, в элемент с role="menu" должен быть вложен как минимум один с menuitem. Однако главное правило — стараться как можно реже явно задавать роли, особенно таким образом переопределять семантику элементов.
Что там в документации
В WAI-ARIA (Web Accessibility Initiative — Accessible Rich Internet Applications), как в самом очевидном источнике о role="", нет примеров с двумя ролями. И про несколько значений у этого атрибута пришлось поискать.
WAI-ARIA
В пункте 7.1. Атрибут роли из WAI-ARIA 1.1 собраны характеристики атрибута роли, которые нужно учитывать в языках реализации (host languages):
  • Имя атрибута должно быть role.
  • Значение атрибута должно допускать список токенов в качестве значения.
  • Появление имени литерала любой конкретной роли в качестве одного из токенов не должно само по себе делать недопустимым значение атрибута в синтаксисе языка реализации.
  • Первый литерал имени неабстрактной роли в списке токенов атрибута role определяет роль в соответствии с тем, как User Agent должен обрабатывать элемент. То, как User Agent обрабатывает роли, установлено в Core Accessibility API Mappings 1.1.
В WAI-ARIA 1.2 и 1.3 нужная информация находится в пункте 8.1. Атрибут роли:
  • Значение атрибута должно допускать список токенов в качестве значения.
  • Появление имени литерала любой конкретной роли в качестве одного из токенов не должно само по себе делать недопустимым значение атрибута в синтаксисе языка реализации.
  • Первый литерал имени неабстрактной роли в списке токенов атрибута role определяет роль в соответствии с тем, как User Agent должен обрабатывать элемент. То, как User Agent обрабатывает роли, установлено в Core Accessibility API Mappings 1.2.
Раз WAI-ARIA отсылает нас к другой документации, давайте почитаем теперь её.
Core Accessibility API Mappings
Core Accessibility API Mappings (Core-AAM для краткости) — это спецификация для браузеров и других User Agent. В ней описано, как они должны взаимодействовать с Accessibility API.
В пункте 5.4. Мапинг ролей из Core-AAM 1.1 есть то, что нам нужно:
Традиционно Accessibility API платформы имеют ограниченный набор заранее установленных ролей, которые ожидаются вспомогательными технологиями на этой платформе, и предоставлены могут быть только одна или две роли. Напротив, WAI-ARIA позволяет указывать несколько ролей в виде упорядоченного набора валидных токенов ролей, разделённых пробелами. Дополнительные роли — фолбэк для других ролей, что похоже на концепцию указания нескольких шрифтов на случай, если первый тип шрифта не поддерживается.
В этом пункте собраны и сами правила работы с ролями из WAI-ARIA.
  1. User Agent должен использовать первый токен в их последовательности в значении атрибута роли, который соответствует имени любой неабстрактной роли из таблицы мапинга ролей… Обратите внимание, что, когда роли из WAI-ARIA перезаписывают семантику языков реализации, то DOM (Document Object Model) не изменяется, только дерево доступности.
  2. User Agent не должен мапировать роли, которые определены в спецификации WAI-ARIA как «абстрактные», с помощью стандартного механизма ролей Accessibility API.
В Core-AAM 1.2 найдёте почти то же самое, но с большим количеством деталей про поддержку ролей разными Accessibility API.
HTML
Давным-давно в HTML-спецификации был пункт 3.2.7.3.1. ARIA-атрибут роли, который тоже описывал возможность добавлять несколько ролей для элемента:
Для каждого HTML-элемента можно указать ARIA-атрибут role. Это атрибут роли из ARIA, который определён в спецификации в Section 5.4 Definition of Roles.
Атрибут, если он задан, должен иметь значение, которое выглядит как набор токенов, разделённых пробелами и представляющих различные роли WAI-ARIA, к которым относится элемент.
Роль WAI-ARIA, которая назначена для HTML-элемента, первая неабстрактная роль, найденная в списке значений, сгенерированных, когда атрибут role разделён пробелами.
Пункта больше нет, но интернет помнит всё.
Перевод с документационного
Какие выводы можно сделать после путешествия по спецификациям?
  • В атрибуте role можно указывать несколько значений.
  • Несколько значений перечисляется стандартно через пробел.
  • Несколько ролей нужны для фолбэка. Если первая роль не поддерживается или не существует, то применяется вторая и так далее.
  • Если это абстрактная роль, то браузер и скринридер её проигнорируют.
Тестируем
Давайте проверим, что будут делать браузеры и скринридеры с двумя значениями в атрибуте role. Поэкспериментируем в Chrome 97, Firefox 96 и Safari 14 с NVDA 2021.2 и десктопным VoiceOver.
Кстати, в старых браузерах и скринридерах это не получится проверить. Они просто игнорируют role="" с несколькими значениями. Имейте это в виду.
Разметка, которую буду тестировать, может напугать. Это проверка работы одного атрибута, так что решила хотя бы раз в жизни использовать запрещённые приёмы 😀 В реальных проектах так лучше никогда не делать. Это ужасный антипаттерн (который можно считать преступлением, ха-ха).
Оба значения существуют
<div
+		}
 
role с несколькими значениями
  • ARIA
 
 Обновлено: 
Недавно случайно узнала, что ARIA-атрибут role может содержать больше одного значения. И это очень неожиданно, по крайней мере для меня.
Этот пост написала из исследовательского интереса, так что в нём нет большого количества полезных практических советов. Что-то даже лучше не применять на практике.
Небольшая справка о роли элемента
Роль содержит информацию о функциях элемента и как с ним можно взаимодействовать. К примеру, о <button> скринридер объявит, что это кнопка, а также сможет на неё нажать.
У элементов может быть либо встроенная роль, либо явно заданная в атрибуте role.
Есть много категорий и видов ролей, и существуют чёткие правила их явного использования. Например, нельзя менять роли при взаимодействии с элементом или задавать абстрактные (landmark, section, widget и другие). Также есть роли, которые предполагают вложенные элементы. Например, в элемент с role="menu" должен быть вложен как минимум один с menuitem. Однако главное правило — стараться как можно реже явно задавать роли, особенно таким образом переопределять семантику элементов.
Что там в документации
В WAI-ARIA (Web Accessibility Initiative — Accessible Rich Internet Applications), как в самом очевидном источнике о role="", нет примеров с двумя ролями. И про несколько значений у этого атрибута пришлось поискать.
WAI-ARIA
В пункте 7.1. Атрибут роли из WAI-ARIA 1.1 собраны характеристики атрибута роли, которые нужно учитывать в языках реализации (host languages):
  • Имя атрибута должно быть role.
  • Значение атрибута должно допускать список токенов в качестве значения.
  • Появление имени литерала любой конкретной роли в качестве одного из токенов не должно само по себе делать недопустимым значение атрибута в синтаксисе языка реализации.
  • Первый литерал имени неабстрактной роли в списке токенов атрибута role определяет роль в соответствии с тем, как User Agent должен обрабатывать элемент. То, как User Agent обрабатывает роли, установлено в Core Accessibility API Mappings 1.1.
В WAI-ARIA 1.2 и 1.3 нужная информация находится в пункте 8.1. Атрибут роли:
  • Значение атрибута должно допускать список токенов в качестве значения.
  • Появление имени литерала любой конкретной роли в качестве одного из токенов не должно само по себе делать недопустимым значение атрибута в синтаксисе языка реализации.
  • Первый литерал имени неабстрактной роли в списке токенов атрибута role определяет роль в соответствии с тем, как User Agent должен обрабатывать элемент. То, как User Agent обрабатывает роли, установлено в Core Accessibility API Mappings 1.2.
Раз WAI-ARIA отсылает нас к другой документации, давайте почитаем теперь её.
Core Accessibility API Mappings
Core Accessibility API Mappings (Core-AAM для краткости) — это спецификация для браузеров и других User Agent. В ней описано, как они должны взаимодействовать с Accessibility API.
В пункте 5.4. Мапинг ролей из Core-AAM 1.1 есть то, что нам нужно:
Традиционно Accessibility API платформы имеют ограниченный набор заранее установленных ролей, которые ожидаются вспомогательными технологиями на этой платформе, и предоставлены могут быть только одна или две роли. Напротив, WAI-ARIA позволяет указывать несколько ролей в виде упорядоченного набора валидных токенов ролей, разделённых пробелами. Дополнительные роли — фолбэк для других ролей, что похоже на концепцию указания нескольких шрифтов на случай, если первый тип шрифта не поддерживается.
В этом пункте собраны и сами правила работы с ролями из WAI-ARIA.
  1. User Agent должен использовать первый токен в их последовательности в значении атрибута роли, который соответствует имени любой неабстрактной роли из таблицы мапинга ролей… Обратите внимание, что, когда роли из WAI-ARIA перезаписывают семантику языков реализации, то DOM (Document Object Model) не изменяется, только дерево доступности.
  2. User Agent не должен мапировать роли, которые определены в спецификации WAI-ARIA как «абстрактные», с помощью стандартного механизма ролей Accessibility API.
В Core-AAM 1.2 найдёте почти то же самое, но с большим количеством деталей про поддержку ролей разными Accessibility API.
HTML
Давным-давно в HTML-спецификации был пункт 3.2.7.3.1. ARIA-атрибут роли, который тоже описывал возможность добавлять несколько ролей для элемента:
Для каждого HTML-элемента можно указать ARIA-атрибут role. Это атрибут роли из ARIA, который определён в спецификации в Section 5.4 Definition of Roles.
Атрибут, если он задан, должен иметь значение, которое выглядит как набор токенов, разделённых пробелами и представляющих различные роли WAI-ARIA, к которым относится элемент.
Роль WAI-ARIA, которая назначена для HTML-элемента, первая неабстрактная роль, найденная в списке значений, сгенерированных, когда атрибут role разделён пробелами.
Пункта больше нет, но интернет помнит всё.
Перевод с документационного
Какие выводы можно сделать после путешествия по спецификациям?
  • В атрибуте role можно указывать несколько значений.
  • Несколько значений перечисляется стандартно через пробел.
  • Несколько ролей нужны для фолбэка. Если первая роль не поддерживается или не существует, то применяется вторая и так далее.
  • Если это абстрактная роль, то браузер и скринридер её проигнорируют.
Тестируем
Давайте проверим, что будут делать браузеры и скринридеры с двумя значениями в атрибуте role. Поэкспериментируем в Chrome 97, Firefox 96 и Safari 14 с NVDA 2021.2 и десктопным VoiceOver.
Кстати, в старых браузерах и скринридерах это не получится проверить. Они просто игнорируют role="" с несколькими значениями. Имейте это в виду.
Разметка, которую буду тестировать, может напугать. Это проверка работы одного атрибута, так что решила хотя бы раз в жизни использовать запрещённые приёмы 😀 В реальных проектах так лучше никогда не делать. Это ужасный антипаттерн (который можно считать преступлением, ха-ха).
Оба значения существуют
<div
   role="button link"
   aria-label="Это не кнопка"
   tabindex="1"
diff --git a/ru/articles/css-media-features-for-a11y/index.html b/ru/articles/css-media-features-for-a11y/index.html
index 2f24311..e43b2fd 100644
--- a/ru/articles/css-media-features-for-a11y/index.html
+++ b/ru/articles/css-media-features-for-a11y/index.html
@@ -21,7 +21,7 @@
 			},
 			"datePublished": "2021-11-01T00:00:00.000Z",
 			"dateModified": "2024-09-05T00:00:00.000Z"
-		}
 
CSS-медиафичи для улучшения доступности
  • CSS
  • Юзабилити
 
 Обновлено: 
Когда говорят про доступность и CSS, часто имеют в виду свойства, которые влияют на дерево доступности и скринридеры. Но есть ещё один союзник в битве за доступность интерфейсов — медиафичи.
Медиафича (media feature) — это условие для CSS-директивы @media. Указывает на определённую характеристику устройства или браузера. К примеру, ориентацию экрана (orientation) или режим отображения (display-mode).
В этом посте расскажу про несколько медиафич: prefers-reduced-motion, prefers-color-scheme, inverted-colors, forced-colors, ms-high-contrast, prefers-contrast и prefers-reduced-transparency. Они отслеживают настройки операционной системы. Настройки изменяют пользователи, которых не устраивает дефолтное поведение системы. К примеру, люди с особыми потребностями и те, кто испытывает дискомфорт из-за дефолтного дизайна.
Так, пользователи с эпилептическими приступами отключают анимацию из-за того, что она может вызвать приступ. А некоторые люди с астигматизмом выбирают тёмную тему и уменьшают контрастность, чтобы не болели глаза.
Учёт пользовательских настроек сделает интерфейс сайта более гибким и персонализированным. Это поможет не только повысить его уровень доступности, но и может повысить конверсию. Всегда приятно пользоваться продуктами, которые учитывают твои предпочтения.
Большинство настроек применяется только к операционной системе. Многие из них, те же анимация и уровень контрастности, не изменяют интерфейсы сайтов. Всё зависит от того, учли ли их разработчики. Как раз здесь помогают медиафичи.
Отслеживать пользовательские настройки можно и с помощью JavaScript, но не хочу раздувать пост ещё больше. Остановлюсь только на возможностях CSS.
Пользовательские настройки
Давайте сначала разберёмся, какие системные настройки можно учитывать в веб-интерфейсах уже сейчас или в будущем.
Анимация
Настройки анимации позволяют изменять её скорость или полностью отключить в системе. Не влияют на сайты, если нет специальных стилей.
Этой настройкой пользуются люди с вестибулярными нарушениями, эпилептическими приступами и с когнитивными особенностями. Особенно пользователи с синдромом дефицита внимания.
Настройка есть во всех операционных системах.
Цветовая схема
Пользователи могут также изменить настройки цветовой схемы и выбрать цвета, которые будут преобладать в системе. Это либо светлые, либо тёмные оттенки. Настройка не влияет на сайты, если на них не поддерживаются цветовые схемы.
Этой настройкой пользуются следующие категории пользователей:
  • с особенностями зрения. Например, со сниженным зрением, глазными болями и повышенной светочувствительностью;
  • с когнитивными особенностями. К примеру, с синдромом дефицита внимания;
  • все остальные из-за эстетических предпочтений, привычки или уровня освещения.
Схемы можно выбрать во всех популярных операционных системах. В macOS и iOS есть дополнительная автоматическая тема. Если она выбрана, то днём применяется светлая тема, а ночью — тёмная.
Инвертирование цветов
Режим инвертированных цветов (inverted colors mode) заменяет системные цвета на противоположные, как на негативе. Относится к режиму экранных фильтров.
Цвета изменяются не только в системе, но и во вкладках браузера. Так что пользователи могут выбрать этот режим вместо тёмной темы. На скриншоте видно, как работает режим инверсии. Жёлтые оттенки стали синими, зелёный — малиновым, белый — чёрным.
Интерфейс сайта в режиме инвертированных цветов.
Сайт Доки с инверсией в Vivaldi на Windows 10.
Кто пользуется настройкой:
  • люди с особенностями зрения, например, с глаукомой или глазными болями;
  • пользователи с мигренями и головными болями;
  • Другие пользователи из-за привычек или освещения.
Настройка есть в большинстве операционных систем. На iOS даже два вида инверсии — «Смарт-инверсия» (Smart Invert) и «Классическая инверсия» (Classic Invert). В режиме умной инверсии картинки и видео не инвертируются. В классическом инвертируется весь контент.
Цветовой режим
Режим принудительных цветов (forced colors mode) ограничивает количество цветов, чтобы повысить читаемость текста за счёт изменения контраста текста и фона. В основном используются цвета с высоким контрастом. Этот режим изменяет цвета и в системе, и на сайтах.
Кто пользуется настройкой:
  • пользователи с особенностями зрения;
  • люди с мигренями и головными болями;
  • люди со светочувствительной эпилепсией;
  • пользователи, которым нужно уменьшить визуальный шум для концентрации внимания.
Пока цветовой режим можно выбрать только в Windows. В Windows 10 и более ранних версиях это режим высокой контрастности (Windows High Contrast Mode, коротко WHCM). В Windows 11 — контрастные темы (Contrast Themes).
В режиме высокой контрастности есть несколько готовых наборов цветов:
  • чёрный режим высокой контрастности (High Contrast Black);
  • белый режим высокой контрастности (High Contrast White);
  • высокая контрастность 1 и 2.
Технология замены цветовой палитры зависит от браузера. Она отличается в браузерах на Chromium, Firefox (движок Quantum), Internet Explorer (Trident) и в старых версиях Edge (EdgeHTML). К примеру, в Vivaldi (Chromium) белый фон сайта стал чёрным, серые ссылки и границы — ярко-жёлтыми, а обычный текст — белым вместо тёмно-серого.
Раздел с подкастами на главной.
«Веб-стандарты» с чёрным режимом высокой контрастности в Vivaldi на Windows 10.
В Firefox цвет изначально белого фон останется таким же, серые ссылки и границы — ярко-синими, а обычный текст — чёрный вместо тёмно-серого.
Список последних эпизодов подкаста «Веб-стандарты».
Своеобразное отображение чёрного режима высокой контрастности в Firefox на Windows 10.
Можно изменить поведение в Firefox по умолчанию. Настройка находится в разделе с настройками языка и внешнего вида (Language and Appearence) и конкретно в подразделе «Цвета» (Colors). Откройте модальное окно кнопкой «Управлять цветами…» (Manage Colors…) и выберите чекбокс «Использовать системные цвета» (Use system colors).
В Windows 11 набор контрастных тем изменился. Появились «Водная» (Aquatic), «Пустыня» (Desert), «Сумерки» (Dusk) и «Ночное небо» (Night sky).
Раздел с подкастами с главной страницы «Веб-стандарты» с системными цветами. Белый фон стал чёрным, ссылки и границы фиолетовые, а обычный текст белый вместо тёмно-серого.
«Веб-стандарты» с режимом ночного неба в Vivaldi на Windows 11.
Если не подходят готовые темы, можно настроить их самостоятельно, в том числе уменьшить контрастность.
Контрастность
Пользователи могут отдельно повысить или понизить уровень контрастности в системе без изменения яркости экрана.
Этой настройкой пользуются пользователи:
  • с особенностями зрения, например, с глаукомой;
  • с мигренями и головными болями;
  • со старыми или некачественными дисплеями;
  • другие, кому не хватает уровня контрастности из-за освещения.
В macOS и iOS есть режим повышенной контрастности (increased contrast mode). Он увеличивает разницу между оттенками серого и делает границы элементов чётче.
Повышение контрастности влияет на внешний вид системы и веб-интерфейсов. В отличие от системных окон, на сайтах изменяется только уровень контрастности. Посмотрим на то, что станет с модальным окном в macOS в обычным режимом и в режиме повышенной контрастности. В обоих окнах открыта картинка с кричащим котом, которая называется «cute-cat.jpeg». У первого окна нет рамки, а фон панели управления с кнопками и дополнительными настройками — светло-серый. Второе окно внешне отличается от первого. У него появилась чёрная рамка, фон панели управления стал белым, а у всех кнопок и других элементов в панели появились отдельные чёрные рамки.
Сравнение окон в обычном режиме и в режиме повышенной контрастности в macOS.
Как ни странно, всё стало более контрастным.
Прозрачность
Пользователи могут включить или выключить прозрачность фона (transparency). Непрозрачный фон часто выбирают те, кто повышает контрастность.
Прозрачный фон может увеличить когнитивную нагрузку и уменьшить читаемость текста. Поэтому этой настройкой пользуются:
  • люди с особенностями зрения. Например, с астигматизмом или сниженным зрением;
  • пользователи с когнитивными особенностями. К примеру, люди с дислексией или синдром дефицита внимания;
  • люди с мигренями и головными болями.
Прозрачность точно настраивается в Windows и на macOS. Эти настройки не только влияют на прозрачность в интерфейсе системы, но и на сайты с браузерами. К примеру, на этом скриншоте фон навигации первого окна полупрозрачный, а у второго — непрозрачный и однотонный.
Сравнение двух окон с включённой и выключенной настройкой.
Так выглядит отключенная прозрачность в Windows 11.
Пара слов про медиатипы
У директивы @media есть несколько медиатипов. Они описывают устройство, на котором отображается документ.
  • all. Все устройства. Задаётся автоматически, если не указать другой тип.
  • screen. Устройства с экранами. Например, телефоны и ноутбуки.
  • print. Устройства с предварительным предпросмотром и функциями печати. Те же принтеры.
  • speech. Устройства с синтезом речи. К примеру, скринридеры и голосовые помощники.
Медиатип speech может быть интересен с точки зрения доступности. Пока что он не поддерживается браузерами. Раньше поддерживался браузером Opera на движке Presto, но перестал после перехода на Blink.
В будущем может пригодиться для специальных стилей для скринридеров. Например, чтобы применить к нужным элементам CSS-свойства для устройств с синтезом речи.
Медиафичи
А вот теперь переходим к медиафичам, которые помогут сделать веб-интерфейсы доступнее.
Часть из них пока не так хорошо поддерживается браузерами. Что-то может измениться в будущем с развитием CSS. В любом случае про них полезно знать.
prefers-reduced-motion
Отслеживает, выбраны ли настройки анимации для уменьшения её интенсивности. Пригодится для любой анимации на сайте. Анимацию можно замедлить или полностью отключить.
Значения prefers-reduced-motion:
  • no-preference, настройки анимации по умолчанию.
  • reduce, изменённые настройки анимации.
У prefers-reduced-motion хорошая поддержка браузерам — 97 % (в 2024).
В этом примере полностью отключаю анимацию через animation: none.
@media (prefers-reduced-motion: reduce) {
+		}
 
CSS-медиафичи для улучшения доступности
  • CSS
  • Юзабилити
 
 Обновлено: 
Когда говорят про доступность и CSS, часто имеют в виду свойства, которые влияют на дерево доступности и скринридеры. Но есть ещё один союзник в битве за доступность интерфейсов — медиафичи.
Медиафича (media feature) — это условие для CSS-директивы @media. Указывает на определённую характеристику устройства или браузера. К примеру, ориентацию экрана (orientation) или режим отображения (display-mode).
В этом посте расскажу про несколько медиафич: prefers-reduced-motion, prefers-color-scheme, inverted-colors, forced-colors, ms-high-contrast, prefers-contrast и prefers-reduced-transparency. Они отслеживают настройки операционной системы. Настройки изменяют пользователи, которых не устраивает дефолтное поведение системы. К примеру, люди с особыми потребностями и те, кто испытывает дискомфорт из-за дефолтного дизайна.
Так, пользователи с эпилептическими приступами отключают анимацию из-за того, что она может вызвать приступ. А некоторые люди с астигматизмом выбирают тёмную тему и уменьшают контрастность, чтобы не болели глаза.
Учёт пользовательских настроек сделает интерфейс сайта более гибким и персонализированным. Это поможет не только повысить его уровень доступности, но и может повысить конверсию. Всегда приятно пользоваться продуктами, которые учитывают твои предпочтения.
Большинство настроек применяется только к операционной системе. Многие из них, те же анимация и уровень контрастности, не изменяют интерфейсы сайтов. Всё зависит от того, учли ли их разработчики. Как раз здесь помогают медиафичи.
Отслеживать пользовательские настройки можно и с помощью JavaScript, но не хочу раздувать пост ещё больше. Остановлюсь только на возможностях CSS.
Пользовательские настройки
Давайте сначала разберёмся, какие системные настройки можно учитывать в веб-интерфейсах уже сейчас или в будущем.
Анимация
Настройки анимации позволяют изменять её скорость или полностью отключить в системе. Не влияют на сайты, если нет специальных стилей.
Этой настройкой пользуются люди с вестибулярными нарушениями, эпилептическими приступами и с когнитивными особенностями. Особенно пользователи с синдромом дефицита внимания.
Настройка есть во всех операционных системах.
Цветовая схема
Пользователи могут также изменить настройки цветовой схемы и выбрать цвета, которые будут преобладать в системе. Это либо светлые, либо тёмные оттенки. Настройка не влияет на сайты, если на них не поддерживаются цветовые схемы.
Этой настройкой пользуются следующие категории пользователей:
  • с особенностями зрения. Например, со сниженным зрением, глазными болями и повышенной светочувствительностью;
  • с когнитивными особенностями. К примеру, с синдромом дефицита внимания;
  • все остальные из-за эстетических предпочтений, привычки или уровня освещения.
Схемы можно выбрать во всех популярных операционных системах. В macOS и iOS есть дополнительная автоматическая тема. Если она выбрана, то днём применяется светлая тема, а ночью — тёмная.
Инвертирование цветов
Режим инвертированных цветов (inverted colors mode) заменяет системные цвета на противоположные, как на негативе. Относится к режиму экранных фильтров.
Цвета изменяются не только в системе, но и во вкладках браузера. Так что пользователи могут выбрать этот режим вместо тёмной темы. На скриншоте видно, как работает режим инверсии. Жёлтые оттенки стали синими, зелёный — малиновым, белый — чёрным.
Интерфейс сайта в режиме инвертированных цветов.
Сайт Доки с инверсией в Vivaldi на Windows 10.
Кто пользуется настройкой:
  • люди с особенностями зрения, например, с глаукомой или глазными болями;
  • пользователи с мигренями и головными болями;
  • Другие пользователи из-за привычек или освещения.
Настройка есть в большинстве операционных систем. На iOS даже два вида инверсии — «Смарт-инверсия» (Smart Invert) и «Классическая инверсия» (Classic Invert). В режиме умной инверсии картинки и видео не инвертируются. В классическом инвертируется весь контент.
Цветовой режим
Режим принудительных цветов (forced colors mode) ограничивает количество цветов, чтобы повысить читаемость текста за счёт изменения контраста текста и фона. В основном используются цвета с высоким контрастом. Этот режим изменяет цвета и в системе, и на сайтах.
Кто пользуется настройкой:
  • пользователи с особенностями зрения;
  • люди с мигренями и головными болями;
  • люди со светочувствительной эпилепсией;
  • пользователи, которым нужно уменьшить визуальный шум для концентрации внимания.
Пока цветовой режим можно выбрать только в Windows. В Windows 10 и более ранних версиях это режим высокой контрастности (Windows High Contrast Mode, коротко WHCM). В Windows 11 — контрастные темы (Contrast Themes).
В режиме высокой контрастности есть несколько готовых наборов цветов:
  • чёрный режим высокой контрастности (High Contrast Black);
  • белый режим высокой контрастности (High Contrast White);
  • высокая контрастность 1 и 2.
Технология замены цветовой палитры зависит от браузера. Она отличается в браузерах на Chromium, Firefox (движок Quantum), Internet Explorer (Trident) и в старых версиях Edge (EdgeHTML). К примеру, в Vivaldi (Chromium) белый фон сайта стал чёрным, серые ссылки и границы — ярко-жёлтыми, а обычный текст — белым вместо тёмно-серого.
Раздел с подкастами на главной.
«Веб-стандарты» с чёрным режимом высокой контрастности в Vivaldi на Windows 10.
В Firefox цвет изначально белого фон останется таким же, серые ссылки и границы — ярко-синими, а обычный текст — чёрный вместо тёмно-серого.
Список последних эпизодов подкаста «Веб-стандарты».
Своеобразное отображение чёрного режима высокой контрастности в Firefox на Windows 10.
Можно изменить поведение в Firefox по умолчанию. Настройка находится в разделе с настройками языка и внешнего вида (Language and Appearence) и конкретно в подразделе «Цвета» (Colors). Откройте модальное окно кнопкой «Управлять цветами…» (Manage Colors…) и выберите чекбокс «Использовать системные цвета» (Use system colors).
В Windows 11 набор контрастных тем изменился. Появились «Водная» (Aquatic), «Пустыня» (Desert), «Сумерки» (Dusk) и «Ночное небо» (Night sky).
Раздел с подкастами с главной страницы «Веб-стандарты» с системными цветами. Белый фон стал чёрным, ссылки и границы фиолетовые, а обычный текст белый вместо тёмно-серого.
«Веб-стандарты» с режимом ночного неба в Vivaldi на Windows 11.
Если не подходят готовые темы, можно настроить их самостоятельно, в том числе уменьшить контрастность.
Контрастность
Пользователи могут отдельно повысить или понизить уровень контрастности в системе без изменения яркости экрана.
Этой настройкой пользуются пользователи:
  • с особенностями зрения, например, с глаукомой;
  • с мигренями и головными болями;
  • со старыми или некачественными дисплеями;
  • другие, кому не хватает уровня контрастности из-за освещения.
В macOS и iOS есть режим повышенной контрастности (increased contrast mode). Он увеличивает разницу между оттенками серого и делает границы элементов чётче.
Повышение контрастности влияет на внешний вид системы и веб-интерфейсов. В отличие от системных окон, на сайтах изменяется только уровень контрастности. Посмотрим на то, что станет с модальным окном в macOS в обычным режимом и в режиме повышенной контрастности. В обоих окнах открыта картинка с кричащим котом, которая называется «cute-cat.jpeg». У первого окна нет рамки, а фон панели управления с кнопками и дополнительными настройками — светло-серый. Второе окно внешне отличается от первого. У него появилась чёрная рамка, фон панели управления стал белым, а у всех кнопок и других элементов в панели появились отдельные чёрные рамки.
Сравнение окон в обычном режиме и в режиме повышенной контрастности в macOS.
Как ни странно, всё стало более контрастным.
Прозрачность
Пользователи могут включить или выключить прозрачность фона (transparency). Непрозрачный фон часто выбирают те, кто повышает контрастность.
Прозрачный фон может увеличить когнитивную нагрузку и уменьшить читаемость текста. Поэтому этой настройкой пользуются:
  • люди с особенностями зрения. Например, с астигматизмом или сниженным зрением;
  • пользователи с когнитивными особенностями. К примеру, люди с дислексией или синдром дефицита внимания;
  • люди с мигренями и головными болями.
Прозрачность точно настраивается в Windows и на macOS. Эти настройки не только влияют на прозрачность в интерфейсе системы, но и на сайты с браузерами. К примеру, на этом скриншоте фон навигации первого окна полупрозрачный, а у второго — непрозрачный и однотонный.
Сравнение двух окон с включённой и выключенной настройкой.
Так выглядит отключенная прозрачность в Windows 11.
Пара слов про медиатипы
У директивы @media есть несколько медиатипов. Они описывают устройство, на котором отображается документ.
  • all. Все устройства. Задаётся автоматически, если не указать другой тип.
  • screen. Устройства с экранами. Например, телефоны и ноутбуки.
  • print. Устройства с предварительным предпросмотром и функциями печати. Те же принтеры.
  • speech. Устройства с синтезом речи. К примеру, скринридеры и голосовые помощники.
Медиатип speech может быть интересен с точки зрения доступности. Пока что он не поддерживается браузерами. Раньше поддерживался браузером Opera на движке Presto, но перестал после перехода на Blink.
В будущем может пригодиться для специальных стилей для скринридеров. Например, чтобы применить к нужным элементам CSS-свойства для устройств с синтезом речи.
Медиафичи
А вот теперь переходим к медиафичам, которые помогут сделать веб-интерфейсы доступнее.
Часть из них пока не так хорошо поддерживается браузерами. Что-то может измениться в будущем с развитием CSS. В любом случае про них полезно знать.
prefers-reduced-motion
Отслеживает, выбраны ли настройки анимации для уменьшения её интенсивности. Пригодится для любой анимации на сайте. Анимацию можно замедлить или полностью отключить.
Значения prefers-reduced-motion:
  • no-preference, настройки анимации по умолчанию.
  • reduce, изменённые настройки анимации.
У prefers-reduced-motion хорошая поддержка браузерам — 97 % (в 2024).
В этом примере полностью отключаю анимацию через animation: none.
@media (prefers-reduced-motion: reduce) {
   .danger-animation {
     animation: none;
   }
diff --git a/ru/articles/how-to-protect-users-with-epilepsy-and-vd/index.html b/ru/articles/how-to-protect-users-with-epilepsy-and-vd/index.html
index 227f3f0..4dd85d8 100644
--- a/ru/articles/how-to-protect-users-with-epilepsy-and-vd/index.html
+++ b/ru/articles/how-to-protect-users-with-epilepsy-and-vd/index.html
@@ -21,7 +21,7 @@
 			},
 			"datePublished": "2021-07-19T00:00:00.000Z",
 			"dateModified": "2024-08-26T00:00:00.000Z"
-		}
 
Как не навредить пользователям с эпилепсией и вестибулярными нарушениями
  • Дизайн
  • Анимация
  • CSS
 
 Обновлено: 
Доступность помогает людям не только без проблем пользоваться интерфейсами, но и не чувствовать себя буквально плохо. С этим могут столкнуться люди с эпилепсией и вестибулярными нарушениями. В сегодняшнем посте расскажу, что значит доступность для этих пользователей.
Вестибулярные нарушения появляются и исчезают спонтанно. Например, из-за побочных эффектов от лекарств, травм головы и даже жаркой погоды. Такая же ситуация с эпилептическими приступами. Мы более-менее готовы к пользователям со скринридерами, но не можем предсказать от чего человеку станет плохо. Поэтому так важно с самого начала не создавать барьеры.
Сначала поговорим про то, что такое вестибулярные нарушения, эпилептические приступы и эпилепсия.
Вестибулярные нарушения
Многих хоть раз укачивало или было чувство тошноты. Причиной мог быть плохой сон, простуда, поездка на машине или пароме и куча других причин.
Вестибулярные нарушения (Vestibular Disorders) связаны с внутренним ухом и частью головного мозга, которая контролирует баланс и движение наших глаз. Это большая группа нарушений. В неё входят травмы головы, вестибулярная мигрень или мигрень с аурой, опухоли мозга и многое другое. Их объединяют похожие симптомы:
  • головокружение;
  • тошнота;
  • размытое зрение;
  • глазная боль;
  • головные боли;
  • спутанность сознания;
  • проблемы с фокусом и концентрацией внимания.
Недоступные интерфейсы могут спровоцировать любой из симптомов. Факундо Коррадини в статье на A List Apart рассказывал как часами лежал в кровати с сильным головокружением после встреч с параллаксом на сайтах.
В мире живёт много людей с вестибулярными нарушениями. Одних только людей с мигренями около 15 % (статистика на 2023).
Эпилептические приступы и эпилепсия
Эпилептический приступ (Seizure) – повышенная активность одновременно множества нейронов в головном мозге. Она приводит к судорогам, параличу, временному сбою внутренних органов, потере или спутанности сознания, частичной амнезии, вспышкам страха и тревожности.
Приступы могут случаться самостоятельно или быть частью целых заболеваний. Если они часто повторяются, то это считается эпилепсией.
Немного статистики. Примерно у 6.5 % людей в мире эпилепсия (статистика на 2019).
На возникновение приступов влияют не только внутренние, но и внешние факторы. Например, свет или звуки. Приступы, спровоцированные светом, звуками и даже чтением, называются рефлекторными. Когда таких приступов много, у человека рефлекторная эпилепсия (Reflex Epilepsy, RE).
Есть несколько типов рефлекторной эпилепсии, но я сосредоточусь на светочувствительной (Photosensitive Epilepsy, PSE). Её провоцируют интенсивный мерцающий свет или движения. Она встречается у 5 % от всего количества людей с эпилепсией. Чаще всего такие приступы случаются в возрасте от 7 до 19 лет, но могут повторяться и позже.
Контент, который мигает, мерцает и вспыхивает, может привести к эпилептическому приступу, ведь он повышает электрическую активность в нейронах.
Проблемный контент
Кто же может стать виновником эпилептического приступа или другой негативной физической реакции?
  • Медиа вроде видео и гифок;
  • canvas;
  • SVG-, CSS- и JavaScript-анимация. Например, когда рядом с текстом есть подвижные изображения или одновременно скроллятся в разных направлениях передний и задний планы — параллакс-эффекты;
  • анимированная прокрутка, которая длится больше одной четвёртой (1/4) секунды или 15 миллисекунд;
  • графика с контрастными полосами, клетками, спиралями и концентрическими кругами;
  • высокая контрастность элементов или всего интерфейса.
Однажды я сама столкнулась с глазной болью и чувством тошноты из-за сплэшскрина в WebStorm 2021.1, хотя это всего лишь статичная картинка. Спасибо команде JetBrains, которая прислушалась к отзывам и снизила насыщенность изображений.
Больше примеров проблемных интерфейсов найдёте в статье Эйлин Уэбб «Your Interactive Makes Me Sick». Надеюсь, ваш вестибулярный аппарат справится с этим испытанием лучше, чем мой.
Вам даже не нужны видео или изображение, чтобы причинить кому-то вред. Простой <div>, который с помощью JavaScript быстро меняет цвет и яркость, тоже может навредить. И мигание можно встретить где угодно. К примеру, спиннеры, которые появляются во время загрузки страниц, могут вращаться и мигать одновременно.
MDN.
Как позаботиться о пользователях
Людей с эпилепсией и вестибулярными нарушениями опасно привлекать к пользовательскому тестированию. Поэтому остаётся действовать превентивно и учитывать рекомендации, которые дают эксперты.
Что же сделать для того, чтобы не навредить пользователям?
Следите за частотой вспышек. Быстрое появление яркого света называют вспышками. Они могут быть обычными (General Flash) или красными (Red Flash). Вспышки встречаются в видео и анимациях.
Обычная вспышка — это быстрое повышение яркости на 10 % и выше и её последующее снижение до 0.8 % и ниже.
Красная вспышка — пара противоположных переходов, между которыми есть насыщенный красный цвет.
Кроме вспышек есть ещё мигания (Blinks). Мигающий контент переключается между двумя состояниями. Обычно он нужен для привлечения внимания к отдельным элементам.
Частота обычных и красных вспышек, а также миганий должна быть не больше трёх (3) раз в секунду или три (3) герца (Гц). Это минимальное требование по доступности для людей со светочувствительной эпилепсией.
Лучшее решение проблемы со вспышками и миганиями — избегать их. Другой выход из ситуации — «безопасная маленькая область» (Small Safe Area). Это приём, когда вы уменьшаете видео или часть страницы с опасной анимацией. Область должна занимать меньше 10 % центральной части поля зрения или меньше 25 % от размера экрана. Дело в том, что центральная часть глаза состоит из большого количества сенсоров. Они активнее других передают сигналы в зрительную кору и могут перегрузить нейроны.
Уменьшение области вспышек и миганий не лучшее решение, так как пользователь может зайти на сайт с мобильного устройства и поднести его слишком близко к глазам.
Что касается миганий, то, если они длятся недолго и автоматически останавливаются, всё хорошо.
Проверить видео и анимацию можете в бесплатной программе Photosensitive Epilepsy Analysis Tool (PEAT). Правда, она подходит только для некоммерческих целей. Для коммерческих есть платная Harding Test.
Выключите анимацию. Можно отключить анимацию, если она не ключевой функционал. Для этого пригодится медиафича prefers-reduced-motion. Она проверяет выбор настроек «Уменьшить движение» (Reduce Motion) в macOS или «Показывать анимацию» (Show Animations) в Windows. Посмотреть на то, как работает медиафича, можно в демке от W3C.
Железобетонных значений для скорости, плавности и других свойств анимации нет. Так что можно воспользоваться опытом других разработчиков или спросить совета у пользователей.
Вариант один (1): только prefers-reduced-motion. Его предлагает Вал Хед.
@media (prefers-reduced-motion: reduce) {
+		}
 
Как не навредить пользователям с эпилепсией и вестибулярными нарушениями
  • Дизайн
  • Анимация
  • CSS
 
 Обновлено: 
Доступность помогает людям не только без проблем пользоваться интерфейсами, но и не чувствовать себя буквально плохо. С этим могут столкнуться люди с эпилепсией и вестибулярными нарушениями. В сегодняшнем посте расскажу, что значит доступность для этих пользователей.
Вестибулярные нарушения появляются и исчезают спонтанно. Например, из-за побочных эффектов от лекарств, травм головы и даже жаркой погоды. Такая же ситуация с эпилептическими приступами. Мы более-менее готовы к пользователям со скринридерами, но не можем предсказать от чего человеку станет плохо. Поэтому так важно с самого начала не создавать барьеры.
Сначала поговорим про то, что такое вестибулярные нарушения, эпилептические приступы и эпилепсия.
Вестибулярные нарушения
Многих хоть раз укачивало или было чувство тошноты. Причиной мог быть плохой сон, простуда, поездка на машине или пароме и куча других причин.
Вестибулярные нарушения (Vestibular Disorders) связаны с внутренним ухом и частью головного мозга, которая контролирует баланс и движение наших глаз. Это большая группа нарушений. В неё входят травмы головы, вестибулярная мигрень или мигрень с аурой, опухоли мозга и многое другое. Их объединяют похожие симптомы:
  • головокружение;
  • тошнота;
  • размытое зрение;
  • глазная боль;
  • головные боли;
  • спутанность сознания;
  • проблемы с фокусом и концентрацией внимания.
Недоступные интерфейсы могут спровоцировать любой из симптомов. Факундо Коррадини в статье на A List Apart рассказывал как часами лежал в кровати с сильным головокружением после встреч с параллаксом на сайтах.
В мире живёт много людей с вестибулярными нарушениями. Одних только людей с мигренями около 15 % (статистика на 2023).
Эпилептические приступы и эпилепсия
Эпилептический приступ (Seizure) – повышенная активность одновременно множества нейронов в головном мозге. Она приводит к судорогам, параличу, временному сбою внутренних органов, потере или спутанности сознания, частичной амнезии, вспышкам страха и тревожности.
Приступы могут случаться самостоятельно или быть частью целых заболеваний. Если они часто повторяются, то это считается эпилепсией.
Немного статистики. Примерно у 6.5 % людей в мире эпилепсия (статистика на 2019).
На возникновение приступов влияют не только внутренние, но и внешние факторы. Например, свет или звуки. Приступы, спровоцированные светом, звуками и даже чтением, называются рефлекторными. Когда таких приступов много, у человека рефлекторная эпилепсия (Reflex Epilepsy, RE).
Есть несколько типов рефлекторной эпилепсии, но я сосредоточусь на светочувствительной (Photosensitive Epilepsy, PSE). Её провоцируют интенсивный мерцающий свет или движения. Она встречается у 5 % от всего количества людей с эпилепсией. Чаще всего такие приступы случаются в возрасте от 7 до 19 лет, но могут повторяться и позже.
Контент, который мигает, мерцает и вспыхивает, может привести к эпилептическому приступу, ведь он повышает электрическую активность в нейронах.
Проблемный контент
Кто же может стать виновником эпилептического приступа или другой негативной физической реакции?
  • Медиа вроде видео и гифок;
  • canvas;
  • SVG-, CSS- и JavaScript-анимация. Например, когда рядом с текстом есть подвижные изображения или одновременно скроллятся в разных направлениях передний и задний планы — параллакс-эффекты;
  • анимированная прокрутка, которая длится больше одной четвёртой (1/4) секунды или 15 миллисекунд;
  • графика с контрастными полосами, клетками, спиралями и концентрическими кругами;
  • высокая контрастность элементов или всего интерфейса.
Однажды я сама столкнулась с глазной болью и чувством тошноты из-за сплэшскрина в WebStorm 2021.1, хотя это всего лишь статичная картинка. Спасибо команде JetBrains, которая прислушалась к отзывам и снизила насыщенность изображений.
Больше примеров проблемных интерфейсов найдёте в статье Эйлин Уэбб «Your Interactive Makes Me Sick». Надеюсь, ваш вестибулярный аппарат справится с этим испытанием лучше, чем мой.
Вам даже не нужны видео или изображение, чтобы причинить кому-то вред. Простой <div>, который с помощью JavaScript быстро меняет цвет и яркость, тоже может навредить. И мигание можно встретить где угодно. К примеру, спиннеры, которые появляются во время загрузки страниц, могут вращаться и мигать одновременно.
MDN.
Как позаботиться о пользователях
Людей с эпилепсией и вестибулярными нарушениями опасно привлекать к пользовательскому тестированию. Поэтому остаётся действовать превентивно и учитывать рекомендации, которые дают эксперты.
Что же сделать для того, чтобы не навредить пользователям?
Следите за частотой вспышек. Быстрое появление яркого света называют вспышками. Они могут быть обычными (General Flash) или красными (Red Flash). Вспышки встречаются в видео и анимациях.
Обычная вспышка — это быстрое повышение яркости на 10 % и выше и её последующее снижение до 0.8 % и ниже.
Красная вспышка — пара противоположных переходов, между которыми есть насыщенный красный цвет.
Кроме вспышек есть ещё мигания (Blinks). Мигающий контент переключается между двумя состояниями. Обычно он нужен для привлечения внимания к отдельным элементам.
Частота обычных и красных вспышек, а также миганий должна быть не больше трёх (3) раз в секунду или три (3) герца (Гц). Это минимальное требование по доступности для людей со светочувствительной эпилепсией.
Лучшее решение проблемы со вспышками и миганиями — избегать их. Другой выход из ситуации — «безопасная маленькая область» (Small Safe Area). Это приём, когда вы уменьшаете видео или часть страницы с опасной анимацией. Область должна занимать меньше 10 % центральной части поля зрения или меньше 25 % от размера экрана. Дело в том, что центральная часть глаза состоит из большого количества сенсоров. Они активнее других передают сигналы в зрительную кору и могут перегрузить нейроны.
Уменьшение области вспышек и миганий не лучшее решение, так как пользователь может зайти на сайт с мобильного устройства и поднести его слишком близко к глазам.
Что касается миганий, то, если они длятся недолго и автоматически останавливаются, всё хорошо.
Проверить видео и анимацию можете в бесплатной программе Photosensitive Epilepsy Analysis Tool (PEAT). Правда, она подходит только для некоммерческих целей. Для коммерческих есть платная Harding Test.
Выключите анимацию. Можно отключить анимацию, если она не ключевой функционал. Для этого пригодится медиафича prefers-reduced-motion. Она проверяет выбор настроек «Уменьшить движение» (Reduce Motion) в macOS или «Показывать анимацию» (Show Animations) в Windows. Посмотреть на то, как работает медиафича, можно в демке от W3C.
Железобетонных значений для скорости, плавности и других свойств анимации нет. Так что можно воспользоваться опытом других разработчиков или спросить совета у пользователей.
Вариант один (1): только prefers-reduced-motion. Его предлагает Вал Хед.
@media (prefers-reduced-motion: reduce) {
   *:not(.safe-animation),
   *:not(.safe-animation)::before,
   *:not(.safe-animation)::after {
diff --git a/ru/articles/index.html b/ru/articles/index.html
index c50988b..52ae9af 100644
--- a/ru/articles/index.html
+++ b/ru/articles/index.html
@@ -1 +1 @@
-Все статьи — Блог о цифровой доступности
 
Все статьи
Клавиатура
Разбираемся с критерием про доступность интерфейса для клавиатуры.
  • WCAG
  • Клавиатура
  • HTML
 
Внешний вид фокуса
Как должны выглядеть элементы при фокусе с клавиатуры по мнению WCAG 2.2.
  • WCAG
  • Дизайн
  • CSS
  • Клавиатура
 
Информация и взаимосвязи
Почему важно подкреплять визуальное представление элементов правильной разметкой.
  • WCAG
  • HTML
  • CSS
  • ARIA
 
Название страницы
Почему у страниц должны быть названия и как их правильно составлять.
  • WCAG
  • HTML
  • Контент
 
Видимый фокус
Разбираемся с критерием о видимом клавиатурном фокусе у интерактивных элементов.
  • WCAG
  • Дизайн
  • CSS
  • Клавиатура
 
Нетекстовое содержимое
Что такое нетекстовое содержимое и текстовые альтернативы.
  • WCAG
  • HTML
  • ARIA
  • Анимация
  • Графика
  • Мультимедиа
 
Сенсорные характеристики
Что такое сенсорные характеристики в инструкциях и как не создать этот барьер.
  • WCAG
  • Контент
  • Дизайн
 
Размер цели
Что такое размер цели, и как не создать такой барьер для пользователей вашего сайта.
  • WCAG
  • UX
  • CSS
 
Консистентная идентификация
Что такое консистентная идентификация на страницах и как не запутать пользователей инструкциями.
  • WCAG
  • Дизайн
  • ARIA
  • HTML
 
role с несколькими значениями
Разберёмся с несколькими значениями у атрибута для роли. В каких случаях это пригодится, и какие отношения с двумя ролями у браузеров и скринридеров.
  • ARIA
 
CSS-медиафичи для улучшения доступности
Какие пользовательские настройки бывают и как их учитывать в веб-интерфейсах. Узнаете про медиафичи, которые отслеживают настройки анимации, контрастности, прозрачности, инверсию, цветовую схему и режим принудительных цветов.
  • CSS
  • Юзабилити
 
Разбираемся со skip link
Как пропустить большую навигацию с помощью skip link, кому нужны такие ссылки и как их добавить на свой сайт.
  • Паттерны
  • HTML
  • CSS
 
Как не навредить пользователям с эпилепсией и вестибулярными нарушениями
Что, если пользователя укачивает из-за сайта? А вдруг у него случится эпилептический приступ? Давайте разберёмся с тем, какими должны быть интерфейсы для пользователей с эпилепсией и вестибулярными нарушениями.
  • Дизайн
  • Анимация
  • CSS
 
 Татьяна Фокина, 2021–2024
Разработано на 11ty, иконки с Lucide Нашли ошибку? Поделитесь ей на GitHub

\ No newline at end of file
+Все статьи — Блог о цифровой доступности
 
Все статьи
Клавиатура
Разбираемся с критерием про доступность интерфейса для клавиатуры.
  • WCAG
  • Клавиатура
  • HTML
 
Внешний вид фокуса
Как должны выглядеть элементы при фокусе с клавиатуры по мнению WCAG 2.2.
  • WCAG
  • Дизайн
  • CSS
  • Клавиатура
 
Информация и взаимосвязи
Почему важно подкреплять визуальное представление элементов правильной разметкой.
  • WCAG
  • HTML
  • CSS
  • ARIA
 
Название страницы
Почему у страниц должны быть названия и как их правильно составлять.
  • WCAG
  • HTML
  • Контент
 
Видимый фокус
Разбираемся с критерием о видимом клавиатурном фокусе у интерактивных элементов.
  • WCAG
  • Дизайн
  • CSS
  • Клавиатура
 
Нетекстовое содержимое
Что такое нетекстовое содержимое и текстовые альтернативы.
  • WCAG
  • HTML
  • ARIA
  • Анимация
  • Графика
  • Мультимедиа
 
Сенсорные характеристики
Что такое сенсорные характеристики в инструкциях и как не создать этот барьер.
  • WCAG
  • Контент
  • Дизайн
 
Размер цели
Что такое размер цели, и как не создать такой барьер для пользователей вашего сайта.
  • WCAG
  • UX
  • CSS
 
Консистентная идентификация
Что такое консистентная идентификация на страницах и как не запутать пользователей инструкциями.
  • WCAG
  • Дизайн
  • ARIA
  • HTML
 
role с несколькими значениями
Разберёмся с несколькими значениями у атрибута для роли. В каких случаях это пригодится, и какие отношения с двумя ролями у браузеров и скринридеров.
  • ARIA
 
CSS-медиафичи для улучшения доступности
Какие пользовательские настройки бывают и как их учитывать в веб-интерфейсах. Узнаете про медиафичи, которые отслеживают настройки анимации, контрастности, прозрачности, инверсию, цветовую схему и режим принудительных цветов.
  • CSS
  • Юзабилити
 
Разбираемся со skip link
Как пропустить большую навигацию с помощью skip link, кому нужны такие ссылки и как их добавить на свой сайт.
  • Паттерны
  • HTML
  • CSS
 
Как не навредить пользователям с эпилепсией и вестибулярными нарушениями
Что, если пользователя укачивает из-за сайта? А вдруг у него случится эпилептический приступ? Давайте разберёмся с тем, какими должны быть интерфейсы для пользователей с эпилепсией и вестибулярными нарушениями.
  • Дизайн
  • Анимация
  • CSS
 
 Татьяна Фокина, 2021–2024
Разработано на 11ty, иконки с Lucide Нашли ошибку? Поделитесь ей на GitHub

\ No newline at end of file
diff --git a/ru/articles/understanding-a-skip-link/index.html b/ru/articles/understanding-a-skip-link/index.html
index adad00d..46a0259 100644
--- a/ru/articles/understanding-a-skip-link/index.html
+++ b/ru/articles/understanding-a-skip-link/index.html
@@ -21,7 +21,7 @@
 			},
 			"datePublished": "2021-08-23T00:00:00.000Z",
 			"dateModified": "2024-06-13T00:00:00.000Z"
-		}
 
Разбираемся со skip link
  • Паттерны
  • HTML
  • CSS
 
 Обновлено: 
В вебе есть много небольших, но полезных доступных паттернов. И один из них — ссылка для пропуска контента или скип линк (skip link). Это гиперссылка, которая ведёт к основному содержанию страницы и помогает пропустить объёмный, часто повторяющийся контент. Её главная цель — экономия времени пользователей.
Какой контент считается объёмным? Навигационное меню с логотипом и кучей ссылок, громоздкая сложная таблица, буквенные указатели, списки с главами или техническими характеристиками. Чаще всего skip link полезна для пропуска навигации по сайту в хедере.
Исключения — меню в футере и небольшая навигация в хедере, которая состоит из пары ссылок и логотипа. В случае футера можно вернуться к началу страницы с помощью клавиш, жестов и других встроенных возможностей браузеров. А небольшая навигация не отнимет много времени у пользователей.
В теории всё просто, но на практике несколько сложнее. Давайте попробуем разобраться со всем по порядку.
Теория
Послушаем WCAG 2.2
В руководстве по доступности есть два критерия, связанные со skip link. Первый касается их косвенно, а второй напрямую.
Механизмы пропуска блоков
Есть два механизма:
  • навигация по ориентирам (landmarks);
  • skip link.
Первый способ доступен для пользователей скринридеров. Ориентиры добавляются с помощью семантических тегов или благодаря ARIA. У второго механизма аудитория больше. Это не только пользователи с особенностями зрения.
Можно встретить совет о том, что skip link не нужна на сайте с хорошей семантической вёрсткой. Это не совсем верно. Не все пользователи скринридеров знают о шорткатах для открытия меню с ориентирами, а у других пользователей клавиатуры такой возможности нет. К тому же, чем больше вариантов навигации, тем лучше.
Кому это нужно
Если коротко, то всем, кто последовательно навигируется по страницам и не может быстро пропустить контент. Если развёрнуто, то четырём категориям пользователей. Это:
  • Пользователи скринридеров, которые перемещаются по десктопным сайтам с помощью клавиатуры, а по мобильным — касаниями, тапами и свайпами.
  • Пользователи с моторными нарушениями, которые пользуются клавиатурой, выносными компьютерными кнопками и другими переключателями.
  • Любые другие пользователи клавиатуры. Они могут быть продвинутого уровня или у них временно сломалась мышка.
  • Пользователи экранных луп, которые используют для навигации клавиатуру.
Представьте, что используете для навигации клавиатуру и зашли на сайт интернет-магазина, например, Ozon. Вы нашли нужный товар, перешли к нему и снова оказались в начале страницы. Примерно 40 табов и вот наконец можно узнать больше про понравившийся рюкзак. Со skip link вы бы оказались в нужном месте в одно нажатие и не заснули по пути.
Требования к skip link
  • Находится на первом месте в порядке табуляции.
  • Ведёт сразу к основному контенту и устанавливает фокус на нём. Она эффективнее, если на странице одна основная область — <main>.
  • Может располагаться в основной области страницы. В этом случаем она пропускает нужный блок и ведёт в начало следующего.
  • Понятно называется и хорошо описывает, куда ведёт.
  • Может быть всегда видна, а может появляться при фокусе с клавиатуры. В обоих случаях отвечает критериям WCAG.
  • Можно добавлять несколько таких ссылок. Например, одна ведёт к основному контенту, вторая — к поисковой строке. Не стоит перебарщивать с количеством, иначе в ссылках нет смысла.
  • Не должна мешать пользователям мыши. Это дискуссионное требование, но в нём есть разумное зерно. Если такая ссылка всегда видна, то может запутать пользователей мышки. Они не знакомы с этим паттерном, а ещё один способ прокрутки к основному контенту им не нужен.
Практика
В проекте уже должен поддерживаться фокус с клавиатуры и использоваться семантическая вёрстка. Без этого skip link бесполезна.
Размечаем страницу
Перед тем, как перейти к разметке, пара слов про текст ссылки. На англоязычных сайтах чаще всего используют «Skip to main content» или «Skip to content». Кажется, что самые подходящие эквиваленты в русском — «Перейти к основному контенту» или более краткое «К основному контенту». «Содержание» — широкое понятие и означает содержимое страницы или оглавление. «Контент» лучше отражает, куда ведёт ссылка.
Ещё несколько вариантов названия:
  • пропустить навигацию (Skip navigation);
  • пропустить основную навигацию (Skip main navigation);
  • пропустить ссылки в навигации (Skip navigation links).
Теперь поговорим о разметке.
Практическая реализация skip link — якорная ссылка. Лучше добавить её в начало <body> или <header>, если это первый элемент на странице. В примерах буду добавлять её в начало хедера.
<header>
+		}
 
Разбираемся со skip link
  • Паттерны
  • HTML
  • CSS
 
 Обновлено: 
В вебе есть много небольших, но полезных доступных паттернов. И один из них — ссылка для пропуска контента или скип линк (skip link). Это гиперссылка, которая ведёт к основному содержанию страницы и помогает пропустить объёмный, часто повторяющийся контент. Её главная цель — экономия времени пользователей.
Какой контент считается объёмным? Навигационное меню с логотипом и кучей ссылок, громоздкая сложная таблица, буквенные указатели, списки с главами или техническими характеристиками. Чаще всего skip link полезна для пропуска навигации по сайту в хедере.
Исключения — меню в футере и небольшая навигация в хедере, которая состоит из пары ссылок и логотипа. В случае футера можно вернуться к началу страницы с помощью клавиш, жестов и других встроенных возможностей браузеров. А небольшая навигация не отнимет много времени у пользователей.
В теории всё просто, но на практике несколько сложнее. Давайте попробуем разобраться со всем по порядку.
Теория
Послушаем WCAG 2.2
В руководстве по доступности есть два критерия, связанные со skip link. Первый касается их косвенно, а второй напрямую.
Механизмы пропуска блоков
Есть два механизма:
  • навигация по ориентирам (landmarks);
  • skip link.
Первый способ доступен для пользователей скринридеров. Ориентиры добавляются с помощью семантических тегов или благодаря ARIA. У второго механизма аудитория больше. Это не только пользователи с особенностями зрения.
Можно встретить совет о том, что skip link не нужна на сайте с хорошей семантической вёрсткой. Это не совсем верно. Не все пользователи скринридеров знают о шорткатах для открытия меню с ориентирами, а у других пользователей клавиатуры такой возможности нет. К тому же, чем больше вариантов навигации, тем лучше.
Кому это нужно
Если коротко, то всем, кто последовательно навигируется по страницам и не может быстро пропустить контент. Если развёрнуто, то четырём категориям пользователей. Это:
  • Пользователи скринридеров, которые перемещаются по десктопным сайтам с помощью клавиатуры, а по мобильным — касаниями, тапами и свайпами.
  • Пользователи с моторными нарушениями, которые пользуются клавиатурой, выносными компьютерными кнопками и другими переключателями.
  • Любые другие пользователи клавиатуры. Они могут быть продвинутого уровня или у них временно сломалась мышка.
  • Пользователи экранных луп, которые используют для навигации клавиатуру.
Представьте, что используете для навигации клавиатуру и зашли на сайт интернет-магазина, например, Ozon. Вы нашли нужный товар, перешли к нему и снова оказались в начале страницы. Примерно 40 табов и вот наконец можно узнать больше про понравившийся рюкзак. Со skip link вы бы оказались в нужном месте в одно нажатие и не заснули по пути.
Требования к skip link
  • Находится на первом месте в порядке табуляции.
  • Ведёт сразу к основному контенту и устанавливает фокус на нём. Она эффективнее, если на странице одна основная область — <main>.
  • Может располагаться в основной области страницы. В этом случаем она пропускает нужный блок и ведёт в начало следующего.
  • Понятно называется и хорошо описывает, куда ведёт.
  • Может быть всегда видна, а может появляться при фокусе с клавиатуры. В обоих случаях отвечает критериям WCAG.
  • Можно добавлять несколько таких ссылок. Например, одна ведёт к основному контенту, вторая — к поисковой строке. Не стоит перебарщивать с количеством, иначе в ссылках нет смысла.
  • Не должна мешать пользователям мыши. Это дискуссионное требование, но в нём есть разумное зерно. Если такая ссылка всегда видна, то может запутать пользователей мышки. Они не знакомы с этим паттерном, а ещё один способ прокрутки к основному контенту им не нужен.
Практика
В проекте уже должен поддерживаться фокус с клавиатуры и использоваться семантическая вёрстка. Без этого skip link бесполезна.
Размечаем страницу
Перед тем, как перейти к разметке, пара слов про текст ссылки. На англоязычных сайтах чаще всего используют «Skip to main content» или «Skip to content». Кажется, что самые подходящие эквиваленты в русском — «Перейти к основному контенту» или более краткое «К основному контенту». «Содержание» — широкое понятие и означает содержимое страницы или оглавление. «Контент» лучше отражает, куда ведёт ссылка.
Ещё несколько вариантов названия:
  • пропустить навигацию (Skip navigation);
  • пропустить основную навигацию (Skip main navigation);
  • пропустить ссылки в навигации (Skip navigation links).
Теперь поговорим о разметке.
Практическая реализация skip link — якорная ссылка. Лучше добавить её в начало <body> или <header>, если это первый элемент на странице. В примерах буду добавлять её в начало хедера.
<header>
   <a href="#main-content" class="skip-link">
     К основному контенту
   </a>
diff --git a/ru/articles/wcag-character-key/index.html b/ru/articles/wcag-character-key/index.html
index 3aa52a0..4208104 100644
--- a/ru/articles/wcag-character-key/index.html
+++ b/ru/articles/wcag-character-key/index.html
@@ -21,4 +21,4 @@
 			},
 			"datePublished": "2022-11-14T00:00:00.000Z",
 			"dateModified": "2024-08-27T00:00:00.000Z"
-		}
 
Клавиша символа в клавиатурном сокращении
  • WCAG
  • Дизайн
  • Клавиатура
 
 Обновлено: 
В этом посте из серии про разбор Руководств по доступности веб-контента (Web Content Accessibility Guidelines, коротко WCAG) расскажу про критерий 2.1.4: клавиша символа в клавиатурном сокращении.
Это базовый критерий уровня A, и он связан с принципом управляемости и с доступностью управления с клавиатуры.
Коротко о критерии
Если используете в клавиатурном сокращении только букву, символ или цифру, у пользователя должна быть возможность его отключить, переназначить или применить только при фокусе на элементе.
Подробнее
Критерий про клавишу символа касается сайтов, программ и приложений, где есть авторские клавиатурные сокращения. Они часто встречаются в редакторах кода, текстовых редакторах и почтовых клиентах.
Критерий подразумевает, что лучше всего использовать клавиатурные сокращения с клавишами-модификаторами. То есть, сокращения не должны состоять только из букв, символов и любых других клавиш с тем, что можно напечатать (non-printable key).
На реальных сайтах и в приложениях часто удобнее и привычнее использовать клавиши с буквами. Например, в видеоплеерах. В этом случае можно сделать следующее:
  • добавить на странице или в настройки элемент, который отключает клавиатурные сокращения;
  • дать возможность перенастроить сокращения.
Если клавиатурное сокращение с буквой, символом или цифрой срабатывает только при фокусе на элементе, это тоже соответствует критерию. Например выпадающее меню, которое открывается при клике на кнопке «Открыть меню» или при нажатии на клавишу m, когда кнопка в фокусе.
Кому это важно
  • Пользователи, которые взаимодействуют с интерфейсом голосом. Например, используют речевой ввод.
  • Все пользователи клавиатуры — пользователи скринридеров, экранных луп, пользователи с особенностями моторики, например, с церебральным параличом, ампутированными пальцами, протезами.
  • Пользователи небольших портативных клавиатур.
  • Люди с когнитивными особенностями, которым удобно назначать одни и те же клавиши для одной команды на разных сайтах и в приложениях.
В первую очередь критерий связан с пользователями голосового управления. В этих программах есть несколько режимов. Один только для команд, другой для голосового ввода текста, и ещё есть смешанный режим, в котором можно надиктовывать текст и выполнять команды. Чаще всего используют смешанный режим. Он удобнее, не нужно переключаться между разными режимами.
При наборе слова по буквам вместо буквы может выполнится одна или даже несколько команд, если в клавиатурных сокращениях используются только клавиши с буквами. Команды могут активировать даже посторонние звуки, если включён микрофон.
Как избежать барьер
Чаще всего проблемы с клавиатурными сокращениями возникают на этапе проработки дизайна взаимодействия (interaction design) и написания кода.
Важно найти баланс между лёгкостью нажатия на клавиши и тем, как при этом сложно сделать ошибку. Можно всегда использовать клавиши-модификаторы в любых клавиатурных сокращениях или дать пользователям гибкие настройки для команд, когда их много.
Примеры соответствия критерию
  • На сайте есть модальное окно с настройками, его можно открыть при помощи Alt + O.
  • В веб-приложении клавиша / (косая черта) делает фокус на поле поиска, но пользователь может её отключить с помощью переключателя в настройках своего профиля.
  • На сайте видео разворачивается на весь экран с помощью F, но пользователь может зайти в настройки и изменить клавиши для этой команды.
В Gmail много клавиатурных сокращений из одного символа или знака. Например, / (косая черта) для поиска по письмам или g для перехода к следующей странице. Эти сокращения можно отключить и настроить. В списке всех настроек откройте вкладку с продвинутыми настройками (advanced) и включите кастомные клавиатурные сокращения (custom keyboard shortcuts). После появится отдельная вкладка «Клавиатурные сокращения» («Keyboard Shortcuts»), в которой можно переназначить клавиши для разных команд.
Клавиши собраны в одну таблицу. В первой колонке хранятся текущие клавиатурные сокращения, по умолчанию она пустая. Во второй колонке «Действия» перечислены команды. Например, открыть окно, искать контакты в чате, упорядочить, искать электронное письмо и так далее. В последней колонке «Клавиша/клавишы» перечислены клавиши по умолчанию и их альтернативы. Например, знак вопроса, Esc, косая черта, стрелка вниз, вправо, влево и тому подобное. Все поля с клавишами кликабельные, в них можно ввести свои варианты сокращений.
Настройки клавиатурных сокращений в почтовом сервисе.
Интерфейс Gmail.
В GitHub тоже есть команды, которые выполняются одной клавишей с буквой или знаком. Например, s делает фокус на поле поиска, а . (точка) открывает редактор кода. В настройках профиля можно отключить клавиатурные сокращения или изменить их. Для этого зайдите в настройки профиля, выберите вкладку «Accessibility» («Доступность») и отожмите чекбокс «Character Keys» («Клавиши символов»). Теперь можно настроить клавиши-модификаторы для клавиатурных сокращений в подразделе «Command Palette» («Палитра команд»). Для этого надо выбрать из выпадающих списков «Search mode» («Режим поиска») и «Command mode» («Режим команд») подходящую опцию.
На скриншоте показано, как это выглядит в самом интерфейсе GitHub. Рядом со всеми элементами управления есть подсказки. Например, про то, что клавиши по умолчанию можно отключить и взамен использовать команды с клавишами-модификаторами. В выпадающем списке «Режим команд» есть несколько клавиш на выбор. Это Ctrl Shift k (по умолчанию), Ctrl k, Ctrl Alt k, Ctrl p, Ctrl Shift p и пункт для отключения шорткатов.
Настройки клавиатурных сокращений для платформы.
Интерфейс GitHub.
Примеры барьеров
  • На сайте есть поиск, к которому можно перейти с помощью клавиши S. У пользователя нет возможности отключить это клавиатурное сокращение или переназначить клавишу.
  • В приложении есть кнопка для открытия модального окна. Ещё окно открывается клавишей + (плюс), даже когда кнопка не в фокусе.
В десктопной версии YouTube есть много клавиатурных сокращений. Например, F раскрывает видео на весь экран, k ставит видео на паузу или продолжает воспроизведение, c включает или выключает субтитры, а , (запятая) перематывает к следующему кадру, когда видео на паузе. Однако на сайте нельзя отключить клавиатурные сокращения или переназначить клавиши.
Список сокращений спрятан в модальном окне. Визуально список выглядит как таблица, состоящая из двух колонок без заголовков. В первой перечислены команды, во второй — клавиши. Например, переключить воспроизведение/паузу — k, перемотать на десять (10) секунд — j и так далее.
Модальное окно с клавиатурными сокращениями для управления видео.
Кусочек интерфейса YouTube.
Как тестировать
Протестировать критерий поможет ручное или автоматическое тестирование.
  • Найдите страницы или экраны, где есть клавиатурные сокращения.
  • Найдите все сокращения, где используются только клавиши с буквами, символами или цифрами.
  • Проверьте, как выполняются команды. Это происходит только при фокусе на элементе или на всей странице.
  • Если команда срабатывает без фокуса на элементе, убедитесь, что её можно отключить или переназначить.
Проще всего поискать во всех .js-файлах по ключевым словам, связанным с клавишами. Например, keydown, keyup или keypress. Ещё можно написать скрипт, который будет нажимать все возможные клавиши на страницах и выводить, например, в консоль сообщение о том, какие клавиши он обнаружил. Так это сделано в довольно старом букмарклете Trigger character key shortcuts.
Что почитать
Другие статьи
 Татьяна Фокина, 2021–2024
Разработано на 11ty, иконки с Lucide Нашли ошибку? Поделитесь ей на GitHub

\ No newline at end of file
+		}
 
Клавиша символа в клавиатурном сокращении
  • WCAG
  • Дизайн
  • Клавиатура
 
 Обновлено: 
В этом посте из серии про разбор Руководств по доступности веб-контента (Web Content Accessibility Guidelines, коротко WCAG) расскажу про критерий 2.1.4: клавиша символа в клавиатурном сокращении.
Это базовый критерий уровня A, и он связан с принципом управляемости и с доступностью управления с клавиатуры.
Коротко о критерии
Если используете в клавиатурном сокращении только букву, символ или цифру, у пользователя должна быть возможность его отключить, переназначить или применить только при фокусе на элементе.
Подробнее
Критерий про клавишу символа касается сайтов, программ и приложений, где есть авторские клавиатурные сокращения. Они часто встречаются в редакторах кода, текстовых редакторах и почтовых клиентах.
Критерий подразумевает, что лучше всего использовать клавиатурные сокращения с клавишами-модификаторами. То есть, сокращения не должны состоять только из букв, символов и любых других клавиш с тем, что можно напечатать (non-printable key).
На реальных сайтах и в приложениях часто удобнее и привычнее использовать клавиши с буквами. Например, в видеоплеерах. В этом случае можно сделать следующее:
  • добавить на странице или в настройки элемент, который отключает клавиатурные сокращения;
  • дать возможность перенастроить сокращения.
Если клавиатурное сокращение с буквой, символом или цифрой срабатывает только при фокусе на элементе, это тоже соответствует критерию. Например выпадающее меню, которое открывается при клике на кнопке «Открыть меню» или при нажатии на клавишу m, когда кнопка в фокусе.
Кому это важно
  • Пользователи, которые взаимодействуют с интерфейсом голосом. Например, используют речевой ввод.
  • Все пользователи клавиатуры — пользователи скринридеров, экранных луп, пользователи с особенностями моторики, например, с церебральным параличом, ампутированными пальцами, протезами.
  • Пользователи небольших портативных клавиатур.
  • Люди с когнитивными особенностями, которым удобно назначать одни и те же клавиши для одной команды на разных сайтах и в приложениях.
В первую очередь критерий связан с пользователями голосового управления. В этих программах есть несколько режимов. Один только для команд, другой для голосового ввода текста, и ещё есть смешанный режим, в котором можно надиктовывать текст и выполнять команды. Чаще всего используют смешанный режим. Он удобнее, не нужно переключаться между разными режимами.
При наборе слова по буквам вместо буквы может выполнится одна или даже несколько команд, если в клавиатурных сокращениях используются только клавиши с буквами. Команды могут активировать даже посторонние звуки, если включён микрофон.
Как избежать барьер
Чаще всего проблемы с клавиатурными сокращениями возникают на этапе проработки дизайна взаимодействия (interaction design) и написания кода.
Важно найти баланс между лёгкостью нажатия на клавиши и тем, как при этом сложно сделать ошибку. Можно всегда использовать клавиши-модификаторы в любых клавиатурных сокращениях или дать пользователям гибкие настройки для команд, когда их много.
Примеры соответствия критерию
  • На сайте есть модальное окно с настройками, его можно открыть при помощи Alt + O.
  • В веб-приложении клавиша / (косая черта) делает фокус на поле поиска, но пользователь может её отключить с помощью переключателя в настройках своего профиля.
  • На сайте видео разворачивается на весь экран с помощью F, но пользователь может зайти в настройки и изменить клавиши для этой команды.
В Gmail много клавиатурных сокращений из одного символа или знака. Например, / (косая черта) для поиска по письмам или g для перехода к следующей странице. Эти сокращения можно отключить и настроить. В списке всех настроек откройте вкладку с продвинутыми настройками (advanced) и включите кастомные клавиатурные сокращения (custom keyboard shortcuts). После появится отдельная вкладка «Клавиатурные сокращения» («Keyboard Shortcuts»), в которой можно переназначить клавиши для разных команд.
Клавиши собраны в одну таблицу. В первой колонке хранятся текущие клавиатурные сокращения, по умолчанию она пустая. Во второй колонке «Действия» перечислены команды. Например, открыть окно, искать контакты в чате, упорядочить, искать электронное письмо и так далее. В последней колонке «Клавиша/клавишы» перечислены клавиши по умолчанию и их альтернативы. Например, знак вопроса, Esc, косая черта, стрелка вниз, вправо, влево и тому подобное. Все поля с клавишами кликабельные, в них можно ввести свои варианты сокращений.
Настройки клавиатурных сокращений в почтовом сервисе.
Интерфейс Gmail.
В GitHub тоже есть команды, которые выполняются одной клавишей с буквой или знаком. Например, s делает фокус на поле поиска, а . (точка) открывает редактор кода. В настройках профиля можно отключить клавиатурные сокращения или изменить их. Для этого зайдите в настройки профиля, выберите вкладку «Accessibility» («Доступность») и отожмите чекбокс «Character Keys» («Клавиши символов»). Теперь можно настроить клавиши-модификаторы для клавиатурных сокращений в подразделе «Command Palette» («Палитра команд»). Для этого надо выбрать из выпадающих списков «Search mode» («Режим поиска») и «Command mode» («Режим команд») подходящую опцию.
На скриншоте показано, как это выглядит в самом интерфейсе GitHub. Рядом со всеми элементами управления есть подсказки. Например, про то, что клавиши по умолчанию можно отключить и взамен использовать команды с клавишами-модификаторами. В выпадающем списке «Режим команд» есть несколько клавиш на выбор. Это Ctrl Shift k (по умолчанию), Ctrl k, Ctrl Alt k, Ctrl p, Ctrl Shift p и пункт для отключения шорткатов.
Настройки клавиатурных сокращений для платформы.
Интерфейс GitHub.
Примеры барьеров
  • На сайте есть поиск, к которому можно перейти с помощью клавиши S. У пользователя нет возможности отключить это клавиатурное сокращение или переназначить клавишу.
  • В приложении есть кнопка для открытия модального окна. Ещё окно открывается клавишей + (плюс), даже когда кнопка не в фокусе.
В десктопной версии YouTube есть много клавиатурных сокращений. Например, F раскрывает видео на весь экран, k ставит видео на паузу или продолжает воспроизведение, c включает или выключает субтитры, а , (запятая) перематывает к следующему кадру, когда видео на паузе. Однако на сайте нельзя отключить клавиатурные сокращения или переназначить клавиши.
Список сокращений спрятан в модальном окне. Визуально список выглядит как таблица, состоящая из двух колонок без заголовков. В первой перечислены команды, во второй — клавиши. Например, переключить воспроизведение/паузу — k, перемотать на десять (10) секунд — j и так далее.
Модальное окно с клавиатурными сокращениями для управления видео.
Кусочек интерфейса YouTube.
Как тестировать
Протестировать критерий поможет ручное или автоматическое тестирование.
  • Найдите страницы или экраны, где есть клавиатурные сокращения.
  • Найдите все сокращения, где используются только клавиши с буквами, символами или цифрами.
  • Проверьте, как выполняются команды. Это происходит только при фокусе на элементе или на всей странице.
  • Если команда срабатывает без фокуса на элементе, убедитесь, что её можно отключить или переназначить.
Проще всего поискать во всех .js-файлах по ключевым словам, связанным с клавишами. Например, keydown, keyup или keypress. Ещё можно написать скрипт, который будет нажимать все возможные клавиши на страницах и выводить, например, в консоль сообщение о том, какие клавиши он обнаружил. Так это сделано в довольно старом букмарклете Trigger character key shortcuts.
Что почитать
Другие статьи
 Татьяна Фокина, 2021–2024
Разработано на 11ty, иконки с Lucide Нашли ошибку? Поделитесь ей на GitHub

\ No newline at end of file
diff --git a/ru/articles/wcag-consistent-identification/index.html b/ru/articles/wcag-consistent-identification/index.html
index 58e1b38..fc10730 100644
--- a/ru/articles/wcag-consistent-identification/index.html
+++ b/ru/articles/wcag-consistent-identification/index.html
@@ -21,4 +21,4 @@
 			},
 			"datePublished": "2022-10-22T00:00:00.000Z",
 			"dateModified": "2024-02-02T00:00:00.000Z"
-		}
 
Консистентная идентификация
  • WCAG
  • Дизайн
  • ARIA
  • HTML
 
 Обновлено: 
В Руководстве по доступности веб-контента (Web Content Accessibility Guidelines или коротко WCAG) описаны барьеры, которые лучше избегать в цифровых продуктах.
Проблема WCAG в том, что не всегда понятно, что руководства хотят от дизайнеров, разработчиков и других специалистов. Так что решила написать серию постов с коротким разбором критериев простым языком.
Первый пост серии про критерий 3.2.4: Консистентная идентификация. Критерий входит в руководство про понятность и он уровня AA, поэтому точно столкнётесь с ним при аудите и тестировании.
Коротко о критерии
Элементы с одинаковой функциональностью выглядят и работают одинаково на разных страницах сайта.
Одинаковая функциональность означает, что элементы делают одно и то же. К примеру, открывают одно диалоговое окно или ведут на одну страницу.
Хотя критерий об элементах на разных страницах, хорошо следить и за консистентностью на одной странице.
Подробнее
Критерий касается интерактивных элементов, к примеру, кнопок, ссылок, вкладок и подобного. У консистентных элементов примерно одинаковые:
  • названия — которые видно визуально или только вспомогательным технологиям;
  • функции — как один и тот же элемент работает на разных страницах;
  • внешний вид — иконки, стили и прочее.
Названия элементов не обязательно должны быть одинаковыми и могут немного отличаться. Ничего страшного, если одна кнопка называется «Перейти к следующему слайду», а у другая — «Перейти к слайду 2». Другой пример — две ссылки с немного разным текстом, которые ведут на одну и ту же страницу. Это тоже не нарушает критерий.
Кому это важно
  • Все пользователи, которые ищут элементы с одинаковой функциональностью на разных страницах сайтов. Например, ссылку на личный кабинет.
  • Пользователи с когнитивными особенностями — с дислексией, синдромом дефицита внимания и другими нейроотличиями.
  • Люди, которым нужны текстовые альтернативы, — названия кнопок и ссылок, описания изображений. Это любые пользователи вспомогательных технологий, особенно пользователи скринридеров и голосового управления.
Кнопки и ссылки, которые делают одно и то же, но называются по-разному, могут привести к когнитивной перегрузке. Это барьер для людей с небольшими когнитивными ресурсами.
Когнитивная перегрузка — теория о том, как внешние и внутренние факторы влияют на рабочую или оперативную память человека. В оперативной памяти временно хранится важная информаций для решения разных задач.
Кнопка для входа в личный кабинет, которая выглядит по-разному, но ведёт себя одинаково на главной и других страницах, увеличивает внешнюю нагрузку на рабочую память. Это может вызвать стресс, раздражение, фрустрацию и заставить кого-то уйти с сайта из-за когнитивной перегрузки.
Как избежать барьер
Часто проблемы с консистентностью появляются ещё на этапе дизайна. С этим помогает справиться атомарный дизайн и продуманная дизайн-система. На уровне кода следить за консистентностью тоже легче, когда есть дизайн-система и используется компонентный подход.
Примеры соответствия критерию
  • Кнопки с одинаковой иконкой лупы и называнием «Поиск по сайту».
  • Элементы с разными функциями, но с одинаковыми иконками в виде галочки и c разными видимыми названиями «Согласен» и «Получать рассылку».
  • Пагинация со ссылками, в названиях которых есть номера страниц. Например, «Страница 1», «Страница 2», «Страница 3».
На сайте gov.uk есть поиск с кнопкой с иконкой лупы на отдельных страницах и в меню. Иконки и сами кнопки выглядят одинаково, у них везде одно и то же скрытое название «Искать gov.uk» («Search GOV.UK»).
Кусочек интерфейса сайта с поисковой строкой в основной части страницы.
Главная gov.uk.
Перейдём на другую страницу. Например, с информацией о кредитном аккаунте. В меню есть строка поиска по сайту, рядом с которой располагается кнопка с невидимой подписью «Искать gov.uk», как и на главной.
Основное меню с полем поиска по сайту.
Другая страница gov.uk.
На Amazon на страницах с категориями товаров есть пагинация. В ней одинаковые по функциональности элементы с одинаковыми названиями в aria-label — «Current page, page 1», «Current page, page 2» и так далее. Для переключения между страницами есть стрелки «Вперёд» и «Назад», а также конкретные номера страниц.
Страница с товарами для животных.
Пример с пагинацией на Amazon.
Если перейти на другую страницу, блок с пагинацией будет выглядеть точно так же и располагаться в том же месте страницы.
Другая страница торговой площадки с пагинацией под списком товаров.
Убеждаемся, что пагинация на Amazon везде выглядит одинаково.
Примеры барьеров
  • Кнопки с одинаковой иконкой лупы для поиска по сайту, но с разными названиями «Поиск» («Search») и «Найти» («Find»).
  • Ссылки с иконкой в виде дома, которые ведут на главную страницу, но у них разные скрытые названия в aria-label — «Главная» и «Перейти к основной странице сайта».
Как тестировать
Проверить консистентность интерактивных элементов поможет ручное и пользовательское тестирование. Примерные шаги:
  • Сравните элементы с одинаковой функциональностью на разных страницах и убедитесь, что у них одни и те же названия и похожие визуальные стили.
  • Проведите тестирование с пользователями, чтобы найти элементы с одинаковой функциональностью, которые вызывают трудности.
Что почитать
Другие статьи
 Татьяна Фокина, 2021–2024
Разработано на 11ty, иконки с Lucide Нашли ошибку? Поделитесь ей на GitHub

\ No newline at end of file
+		}
 
Консистентная идентификация
  • WCAG
  • Дизайн
  • ARIA
  • HTML
 
 Обновлено: 
В Руководстве по доступности веб-контента (Web Content Accessibility Guidelines или коротко WCAG) описаны барьеры, которые лучше избегать в цифровых продуктах.
Проблема WCAG в том, что не всегда понятно, что руководства хотят от дизайнеров, разработчиков и других специалистов. Так что решила написать серию постов с коротким разбором критериев простым языком.
Первый пост серии про критерий 3.2.4: Консистентная идентификация. Критерий входит в руководство про понятность и он уровня AA, поэтому точно столкнётесь с ним при аудите и тестировании.
Коротко о критерии
Элементы с одинаковой функциональностью выглядят и работают одинаково на разных страницах сайта.
Одинаковая функциональность означает, что элементы делают одно и то же. К примеру, открывают одно диалоговое окно или ведут на одну страницу.
Хотя критерий об элементах на разных страницах, хорошо следить и за консистентностью на одной странице.
Подробнее
Критерий касается интерактивных элементов, к примеру, кнопок, ссылок, вкладок и подобного. У консистентных элементов примерно одинаковые:
  • названия — которые видно визуально или только вспомогательным технологиям;
  • функции — как один и тот же элемент работает на разных страницах;
  • внешний вид — иконки, стили и прочее.
Названия элементов не обязательно должны быть одинаковыми и могут немного отличаться. Ничего страшного, если одна кнопка называется «Перейти к следующему слайду», а у другая — «Перейти к слайду 2». Другой пример — две ссылки с немного разным текстом, которые ведут на одну и ту же страницу. Это тоже не нарушает критерий.
Кому это важно
  • Все пользователи, которые ищут элементы с одинаковой функциональностью на разных страницах сайтов. Например, ссылку на личный кабинет.
  • Пользователи с когнитивными особенностями — с дислексией, синдромом дефицита внимания и другими нейроотличиями.
  • Люди, которым нужны текстовые альтернативы, — названия кнопок и ссылок, описания изображений. Это любые пользователи вспомогательных технологий, особенно пользователи скринридеров и голосового управления.
Кнопки и ссылки, которые делают одно и то же, но называются по-разному, могут привести к когнитивной перегрузке. Это барьер для людей с небольшими когнитивными ресурсами.
Когнитивная перегрузка — теория о том, как внешние и внутренние факторы влияют на рабочую или оперативную память человека. В оперативной памяти временно хранится важная информаций для решения разных задач.
Кнопка для входа в личный кабинет, которая выглядит по-разному, но ведёт себя одинаково на главной и других страницах, увеличивает внешнюю нагрузку на рабочую память. Это может вызвать стресс, раздражение, фрустрацию и заставить кого-то уйти с сайта из-за когнитивной перегрузки.
Как избежать барьер
Часто проблемы с консистентностью появляются ещё на этапе дизайна. С этим помогает справиться атомарный дизайн и продуманная дизайн-система. На уровне кода следить за консистентностью тоже легче, когда есть дизайн-система и используется компонентный подход.
Примеры соответствия критерию
  • Кнопки с одинаковой иконкой лупы и называнием «Поиск по сайту».
  • Элементы с разными функциями, но с одинаковыми иконками в виде галочки и c разными видимыми названиями «Согласен» и «Получать рассылку».
  • Пагинация со ссылками, в названиях которых есть номера страниц. Например, «Страница 1», «Страница 2», «Страница 3».
На сайте gov.uk есть поиск с кнопкой с иконкой лупы на отдельных страницах и в меню. Иконки и сами кнопки выглядят одинаково, у них везде одно и то же скрытое название «Искать gov.uk» («Search GOV.UK»).
Кусочек интерфейса сайта с поисковой строкой в основной части страницы.
Главная gov.uk.
Перейдём на другую страницу. Например, с информацией о кредитном аккаунте. В меню есть строка поиска по сайту, рядом с которой располагается кнопка с невидимой подписью «Искать gov.uk», как и на главной.
Основное меню с полем поиска по сайту.
Другая страница gov.uk.
На Amazon на страницах с категориями товаров есть пагинация. В ней одинаковые по функциональности элементы с одинаковыми названиями в aria-label — «Current page, page 1», «Current page, page 2» и так далее. Для переключения между страницами есть стрелки «Вперёд» и «Назад», а также конкретные номера страниц.
Страница с товарами для животных.
Пример с пагинацией на Amazon.
Если перейти на другую страницу, блок с пагинацией будет выглядеть точно так же и располагаться в том же месте страницы.
Другая страница торговой площадки с пагинацией под списком товаров.
Убеждаемся, что пагинация на Amazon везде выглядит одинаково.
Примеры барьеров
  • Кнопки с одинаковой иконкой лупы для поиска по сайту, но с разными названиями «Поиск» («Search») и «Найти» («Find»).
  • Ссылки с иконкой в виде дома, которые ведут на главную страницу, но у них разные скрытые названия в aria-label — «Главная» и «Перейти к основной странице сайта».
Как тестировать
Проверить консистентность интерактивных элементов поможет ручное и пользовательское тестирование. Примерные шаги:
  • Сравните элементы с одинаковой функциональностью на разных страницах и убедитесь, что у них одни и те же названия и похожие визуальные стили.
  • Проведите тестирование с пользователями, чтобы найти элементы с одинаковой функциональностью, которые вызывают трудности.
Что почитать
Другие статьи
 Татьяна Фокина, 2021–2024
Разработано на 11ty, иконки с Lucide Нашли ошибку? Поделитесь ей на GitHub

\ No newline at end of file
diff --git a/ru/articles/wcag-focus-appearance/index.html b/ru/articles/wcag-focus-appearance/index.html
index 98d9749..0d98f28 100644
--- a/ru/articles/wcag-focus-appearance/index.html
+++ b/ru/articles/wcag-focus-appearance/index.html
@@ -21,6 +21,6 @@
 			},
 			"datePublished": "2023-01-27T00:00:00.000Z",
 			"dateModified": "2024-08-27T00:00:00.000Z"
-		}
 
Внешний вид фокуса
  • WCAG
  • Дизайн
  • CSS
  • Клавиатура
 
 Обновлено: 
В этом посте из серии про разбор Руководств по доступности веб-контента (Web Content Accessibility Guidelines, коротко WCAG) расскажу про новый критерий из WCAG 2.2 — 2.4.11: внешний вид фокуса. Он связан с другим критерием про видимый фокус, про который уже рассказывала раньше.
Критерий про внешний вид фокуса уровня AA. Он относится к принципу управляемости и к руководству про доступность с клавиатуры.
В первоначальной версии черновика WCAG 2.2 было два критерия про то, как должен выглядеть фокус. Один минимальный уровня AA, другой продвинутый уровня AAA. В итоге от продвинутого отказались и оставили только минимальный.
Коротко
Когда элемент интерфейса получает фокус с клавиатуры, индикатор фокуса должен:
  • обводить элемент;
  • иметь соотношение контраста минимум три к одному (3:1) между одними и теми же пикселями в состоянии фокуса и без него;
  • иметь соотношение контраста минимум три к одному (3:1) по отношению к соседним цветам.
Область индикатора фокуса должна:
  • быть толщиной на один (1) CSS-пиксель (дальше просто пиксель) больше минимальной области элемента или больше четырёх (4) пикселей, если индикатор равен самой короткой стороне элемента;
  • иметь соотношение контраста минимум три к одному (3:1) между одними и теми же пикселями в состоянии фокуса и без него;
  • иметь соотношение контраста минимум три к одному (3:1) по отношению к соседним цветам или быть толщиной два (2) пикселя и больше.
Подробнее
В критерии речь идёт о фокусе, который становится виден при навигации с клавиатуры. Таким образом, он касается стилей, которые задаются псевдоклассам :focus или :focus-visible.
Индикатор фокуса (focus indicator) — это изменяющаяся область вокруг или внутри интерактивного элемента, когда на нём сделан фокус. Для пользователей клавиатуры индикатор фокуса — это как курсор для пользователей мыши.
Индикатор фокуса может выглядеть как рамка вокруг элемента (outline) или повторять форму элемента (shape).
Другие важные термины — граница (bound, solidly bound) и окаймление (surround). Граница — это прямоугольная рамка вокруг элемента, которая находится от него на некотором расстоянии. Окаймление — это рамка, которая повторяет форму элемента.
В свою очередь, границы и окаймления могут быть сплошными (solid) и несплошными (non-solid).
Хотя критерий требует использовать сплошное начертание, он не запрещает полностью несплошное — пунктирную линию.
Подытожим новые требованиям к фокусу в виде рамки или окаймления:
  • в первую очередь сплошное начертание, но допустимо пунктирное с большей толщиной;
  • полностью обводит или окаймляет элемент;
  • толщина минимум один (1) пиксель если они вокруг элемента, в том числе круглой формы;
  • толщина минимум два (2) пикселя, когда рамка внутри элемента, она того же цвета, что элемент, или это горизонтальная черта под или над элементом;
  • толщина минимум четыре (4) пикселя, если это пунктирная линия;
  • толщина минимум четыре (4) пикселя, когда это вертикальная черта слева или справа от текста внутри элемента;
  • достаточно контрастная:
    • три к одному (3:1) по отношению к цвету элемента, когда он неактивен (не в фокусе);
    • три к одному (3:1) по отношению к фону страницы.
Индикатор фокуса может быть и в виде двойной рамки. В этом случае контрастной должна быть только одна.
С индикатором фокуса, который повторяет форму элемента, всё довольно просто. Стоит следить за фоном элемента по умолчанию и при фокусе. Эти цвета должны быть контрастны по отношению друг к другу в соотношении три к одному (3:1). Кстати, в критерии отмечают, что менять фон элемента не самая лучшая практика. В этом случае пользователи должны сравнивать элементы между собой чтобы понять, что сейчас в фокусе.
Когда используете обычную или градиентную тень, обращайте внимание на несколько вещей:
  • насколько тень далеко выходит за пределы элемента;
  • как сопоставляется с размерами элемента.
Обычная тень с одним цветом тоже должна быть контрастной в соотношении три к одному (3:1), а вот для градиентной тени это не важно.
Разберём на примере нескольких вариантов кнопок. У одной из прямоугольных кнопок без фокуса чёрный фон и белый текст «Настройки». При фокусе кнопка становится больше, а внутри появляется белая жирная рамка. В другом варианте цвет фона становится белым, а рядом с текстом появляется жирная белая вертикальная черта и не такая жирная горизонтальная.
У другой кнопки со скруглёнными краями по умолчанию серый фон и тёмно-серый текст внутри. Так что при фокусе в одном случаем появляется чёрная сплошная рамка, в другом — пунктирная, а в последнем — размытая серая тень.
Последняя круглая кнопка по умолчанию тоже серая, но внутри, вместо текста, тёмно-серая иконка лупы. В родном случае при фокусе появляется жирная круглая внутренняя рамка, в другом — рамка снаружи, и в последнем — двойная рамка со светло-фиолетовой линией внутри и чёрной снаружи.
Примеры с кнопками разной формы.
Варианты стилей фокуса, которые соответствуют критерию.
Если в элемент вложено несколько интерактивных, критерий про внешний вид фокуса распространяется в первую очередь на дочерние элементы. Например, как в кастомном комбинированном списке или в панели вкладок. При этом в случае таких сложных интерактивных элементов фокус может быть:
  • у всего компонента;
  • у вложенных в него компонентов;
  • одновременно у всего компонента и у вложенных в него элементов.
Для ссылок не критично, если индикатор фокуса не сплошной и одна из его сторон скрывается при переносе ссылки. Обычно это происходит, когда используете свойство border. В любом случае критерий будет пройден при условии, что цвет индикатора фокуса достаточно контрастный.
Наконец, есть несколько исключений. В этих случаях не надо следить за внешним видом индикатора фокуса:
  • Браузерные стили фокуса по умолчанию.
  • Элементы, у которых нельзя поменять стили фокуса по молчанию. К примеру, <select>.
  • Большие интерактивные области как в текстовых редакторах.
  • Неинтерактивные элементы, которые могут в каких-то случаях получать фокус. Например, заголовки.
Немного геометрии
Почему в каких-то случаях достаточно сделать индикатор фокуса в один (1) пиксель, а в каких-то больше? Чтобы ответить на вопрос, надо стряхнуть пыль со школьной геометрии и пару раз перечитать подробное описание критерия.
Общий принцип такой — в состоянии фокуса минимальная область элемента должна быть больше на один (1) пиксель минимум, чем в состоянии по умолчанию.
Чтобы выяснить минимальную область прямоугольного элемента или круглого, надо посчитать их периметр.
В случае прямоугольника умножаем его ширину на два (2), потом толщину и складываем их вместе. Кратко формула выглядит так: 2 × высота + 2 × ширина.
Чтобы вычислить нужный периметр кнопки максимально точно, из периметра вычитаем ещё четыре — сумму пикселей четырёх углов прямоугольника. Таким образом, окончательная формула выглядит так — 2 × высота + 2 × ширина − 4.
Разберём на конкретном примере прямоугольной кнопки шириной 90 пикселей и высотой 30. Умножаем каждую сторону на 2 и складываем их. 90 × 2 × 30 × 2. Получаем 240 пикселей. Теперь вычитаем из получившегося периметра 4 — 240 − 4. Получаем минимальную область 236 пикселей. Индикатор фокуса должен увеличить эту область. Так что, 1 пиксель или даже 3 подходят для рамки вокруг такого элемента.
Для определения периметра круга нужно умножить на два число пи (𝜋) и радиус круга (r). Формула выглядит так — 2𝜋r.
Представим, что у кнопки радиус 22 пикселя. В этом случае умножаем 3.14 на 2 и затем на 22. Округлим число и получим 138 пикселей. В этом случае внешняя рамка может быть шириной 1 пиксель, так как эта область получается больше минимальной. А вот рамка внутри круглой кнопки уже должна быть минимум 2 пикселя.
Рассчитывать каждый раз периметр минимальной области элементов не нужно. Главное понимать общий принцип расчёта толщины индикатора фокуса.
Кому это важно
  • Все пользователи клавиатуры — люди с особенностями моторики, продвинутые пользователи.
  • Люди с когнитивными особенностями, у которых небольшой объём рабочей памяти или они легко отвлекаются и забывают на каком элементе остановились.
Как избежать барьер
За выполнением критерия в первую очередь должны следить дизайнеры. Хорошо проработать заранее стили фокуса для разных интерактивных элементов с учётом их типа, цветовой темы и так далее.
Всегда можно оставить браузерные стили фокуса по умолчанию, но не во всех браузерах они заметные. Если в дизайн-системе есть элементы того же цвета, что браузерные стили по умолчанию, тогда они вообще могут слиться друг с другом.
У разработчиков много способов задать стили для :focus или :focus-visible. Например, с помощью свойств outline, border, box-shadow, text-decoration или background. Подробнее про их плюсы и минусы почитайте в статье «Developing a focus style for a themable design system».
Примеры соответствия критерию
  • Когда ссылка в фокусе, вокруг неё появляется сплошная чёрная рамка шириной два (2) пикселя, которая полностью обводит ссылку со всех сторон. Фон страницы при этом светло-серый.
  • При фокусе на кнопке вокруг неё на небольшом расстоянии появляется сплошная тёмно-синяя рамка толщиной три (3) пикселя. Она достаточно контрастная по отношению к фону страницы.
На сайте сервиса для тестирования Fable используют несколько способов выделения элементов при фокусе. У текстовых ссылок меняется фоновый цвет и цвет текста. В неактивном состоянии ссылки голубого цвета, в фокусе их фон становится голубым, а цвет текста — белым. Нетекстовая ссылка с логотипом при фокусе обводится синей рамкой толщиной в три (3) пикселя.
Кнопки с белым фоном при фокусе обводятся рамкой внутри, толщина которой тоже три (3) пикселя. Кнопки с розовым фоном при фокусе меняют свой фон на белый, они обводятся розовой рамкой, а снаружи появляется ещё одна рамка такой же толщины.
Ссылки и кнопки в разных состояниях. Подробное описание перед картинкой.
Элементы интерфейса Fable.
На gov.uk также обнаружите несколько вариантов стилей для фокуса.
Ссылки по умолчанию синие с тонкой чертой такого же цвета под ними. Когда делаете на них фокус, они становятся чёрными, нижнее подчёркивание тоже становится чёрным и более жирным, а фон меняется на жёлтый.
Что касается текстовых полей, по умолчанию вокруг них тонкая чёрная рамка. При фокусе рамка становится более жирной, дополнительно вокруг неё появляется ещё одна жёлтого цвета.
У некоторых кнопок при фокусе фон с серого меняется на жёлтый, а более жирная нижняя граница увеличивается где-то на три (3) пикселя.
Поле поиска, ссылки и кнопки в состоянии фокуса и без. Подробное описание до картинки.
Интерфейс gov.uk.
Примеры барьеров
  • Вокруг названия вкладки при фокусе появляется пунктирная черта с точками, ширина которой 1 пиксель.
  • При фокусе внутри кнопки рядом с текстом появляется вертикальная черта толщиной 1 пиксель.
На сайте музея Ikea при фокусе на ссылках вокруг них появляется тонкая пунктирная рамка светло-серого цвета или тёмно-серого цвета в зависимости от цвета текста. Для неё используется свойство outline со значением 1px dotted currentColor.
Стили фокуса у ссылки из сообщения о кукиз, слайда из карусели, другой ссылки из футера и у логотипа сайта.
Интерактивные элементы на сайте музея Ikea.
Как тестировать
Тестируйте критерий смешанным способом, как и видимый фокус.
  • Найдите все интерактивные элементы с помощью Tab или скриптом.
  • Убедитесь, что у всех элементов индикатор фокуса соответствует требованиям.
Чтобы найти интерактивные элементы, используйте букмарклеты ANDI или Force Show Keyboard Focus. Другой способ — напишите свой небольшой скрипт и соберите интерактивные элементы в консоли в браузере.
document.addEventListener('focus', () => {
+		}
 
Внешний вид фокуса
  • WCAG
  • Дизайн
  • CSS
  • Клавиатура
 
 Обновлено: 
В этом посте из серии про разбор Руководств по доступности веб-контента (Web Content Accessibility Guidelines, коротко WCAG) расскажу про новый критерий из WCAG 2.2 — 2.4.11: внешний вид фокуса. Он связан с другим критерием про видимый фокус, про который уже рассказывала раньше.
Критерий про внешний вид фокуса уровня AA. Он относится к принципу управляемости и к руководству про доступность с клавиатуры.
В первоначальной версии черновика WCAG 2.2 было два критерия про то, как должен выглядеть фокус. Один минимальный уровня AA, другой продвинутый уровня AAA. В итоге от продвинутого отказались и оставили только минимальный.
Коротко
Когда элемент интерфейса получает фокус с клавиатуры, индикатор фокуса должен:
  • обводить элемент;
  • иметь соотношение контраста минимум три к одному (3:1) между одними и теми же пикселями в состоянии фокуса и без него;
  • иметь соотношение контраста минимум три к одному (3:1) по отношению к соседним цветам.
Область индикатора фокуса должна:
  • быть толщиной на один (1) CSS-пиксель (дальше просто пиксель) больше минимальной области элемента или больше четырёх (4) пикселей, если индикатор равен самой короткой стороне элемента;
  • иметь соотношение контраста минимум три к одному (3:1) между одними и теми же пикселями в состоянии фокуса и без него;
  • иметь соотношение контраста минимум три к одному (3:1) по отношению к соседним цветам или быть толщиной два (2) пикселя и больше.
Подробнее
В критерии речь идёт о фокусе, который становится виден при навигации с клавиатуры. Таким образом, он касается стилей, которые задаются псевдоклассам :focus или :focus-visible.
Индикатор фокуса (focus indicator) — это изменяющаяся область вокруг или внутри интерактивного элемента, когда на нём сделан фокус. Для пользователей клавиатуры индикатор фокуса — это как курсор для пользователей мыши.
Индикатор фокуса может выглядеть как рамка вокруг элемента (outline) или повторять форму элемента (shape).
Другие важные термины — граница (bound, solidly bound) и окаймление (surround). Граница — это прямоугольная рамка вокруг элемента, которая находится от него на некотором расстоянии. Окаймление — это рамка, которая повторяет форму элемента.
В свою очередь, границы и окаймления могут быть сплошными (solid) и несплошными (non-solid).
Хотя критерий требует использовать сплошное начертание, он не запрещает полностью несплошное — пунктирную линию.
Подытожим новые требованиям к фокусу в виде рамки или окаймления:
  • в первую очередь сплошное начертание, но допустимо пунктирное с большей толщиной;
  • полностью обводит или окаймляет элемент;
  • толщина минимум один (1) пиксель если они вокруг элемента, в том числе круглой формы;
  • толщина минимум два (2) пикселя, когда рамка внутри элемента, она того же цвета, что элемент, или это горизонтальная черта под или над элементом;
  • толщина минимум четыре (4) пикселя, если это пунктирная линия;
  • толщина минимум четыре (4) пикселя, когда это вертикальная черта слева или справа от текста внутри элемента;
  • достаточно контрастная:
    • три к одному (3:1) по отношению к цвету элемента, когда он неактивен (не в фокусе);
    • три к одному (3:1) по отношению к фону страницы.
Индикатор фокуса может быть и в виде двойной рамки. В этом случае контрастной должна быть только одна.
С индикатором фокуса, который повторяет форму элемента, всё довольно просто. Стоит следить за фоном элемента по умолчанию и при фокусе. Эти цвета должны быть контрастны по отношению друг к другу в соотношении три к одному (3:1). Кстати, в критерии отмечают, что менять фон элемента не самая лучшая практика. В этом случае пользователи должны сравнивать элементы между собой чтобы понять, что сейчас в фокусе.
Когда используете обычную или градиентную тень, обращайте внимание на несколько вещей:
  • насколько тень далеко выходит за пределы элемента;
  • как сопоставляется с размерами элемента.
Обычная тень с одним цветом тоже должна быть контрастной в соотношении три к одному (3:1), а вот для градиентной тени это не важно.
Разберём на примере нескольких вариантов кнопок. У одной из прямоугольных кнопок без фокуса чёрный фон и белый текст «Настройки». При фокусе кнопка становится больше, а внутри появляется белая жирная рамка. В другом варианте цвет фона становится белым, а рядом с текстом появляется жирная белая вертикальная черта и не такая жирная горизонтальная.
У другой кнопки со скруглёнными краями по умолчанию серый фон и тёмно-серый текст внутри. Так что при фокусе в одном случаем появляется чёрная сплошная рамка, в другом — пунктирная, а в последнем — размытая серая тень.
Последняя круглая кнопка по умолчанию тоже серая, но внутри, вместо текста, тёмно-серая иконка лупы. В родном случае при фокусе появляется жирная круглая внутренняя рамка, в другом — рамка снаружи, и в последнем — двойная рамка со светло-фиолетовой линией внутри и чёрной снаружи.
Примеры с кнопками разной формы.
Варианты стилей фокуса, которые соответствуют критерию.
Если в элемент вложено несколько интерактивных, критерий про внешний вид фокуса распространяется в первую очередь на дочерние элементы. Например, как в кастомном комбинированном списке или в панели вкладок. При этом в случае таких сложных интерактивных элементов фокус может быть:
  • у всего компонента;
  • у вложенных в него компонентов;
  • одновременно у всего компонента и у вложенных в него элементов.
Для ссылок не критично, если индикатор фокуса не сплошной и одна из его сторон скрывается при переносе ссылки. Обычно это происходит, когда используете свойство border. В любом случае критерий будет пройден при условии, что цвет индикатора фокуса достаточно контрастный.
Наконец, есть несколько исключений. В этих случаях не надо следить за внешним видом индикатора фокуса:
  • Браузерные стили фокуса по умолчанию.
  • Элементы, у которых нельзя поменять стили фокуса по молчанию. К примеру, <select>.
  • Большие интерактивные области как в текстовых редакторах.
  • Неинтерактивные элементы, которые могут в каких-то случаях получать фокус. Например, заголовки.
Немного геометрии
Почему в каких-то случаях достаточно сделать индикатор фокуса в один (1) пиксель, а в каких-то больше? Чтобы ответить на вопрос, надо стряхнуть пыль со школьной геометрии и пару раз перечитать подробное описание критерия.
Общий принцип такой — в состоянии фокуса минимальная область элемента должна быть больше на один (1) пиксель минимум, чем в состоянии по умолчанию.
Чтобы выяснить минимальную область прямоугольного элемента или круглого, надо посчитать их периметр.
В случае прямоугольника умножаем его ширину на два (2), потом толщину и складываем их вместе. Кратко формула выглядит так: 2 × высота + 2 × ширина.
Чтобы вычислить нужный периметр кнопки максимально точно, из периметра вычитаем ещё четыре — сумму пикселей четырёх углов прямоугольника. Таким образом, окончательная формула выглядит так — 2 × высота + 2 × ширина − 4.
Разберём на конкретном примере прямоугольной кнопки шириной 90 пикселей и высотой 30. Умножаем каждую сторону на 2 и складываем их. 90 × 2 × 30 × 2. Получаем 240 пикселей. Теперь вычитаем из получившегося периметра 4 — 240 − 4. Получаем минимальную область 236 пикселей. Индикатор фокуса должен увеличить эту область. Так что, 1 пиксель или даже 3 подходят для рамки вокруг такого элемента.
Для определения периметра круга нужно умножить на два число пи (𝜋) и радиус круга (r). Формула выглядит так — 2𝜋r.
Представим, что у кнопки радиус 22 пикселя. В этом случае умножаем 3.14 на 2 и затем на 22. Округлим число и получим 138 пикселей. В этом случае внешняя рамка может быть шириной 1 пиксель, так как эта область получается больше минимальной. А вот рамка внутри круглой кнопки уже должна быть минимум 2 пикселя.
Рассчитывать каждый раз периметр минимальной области элементов не нужно. Главное понимать общий принцип расчёта толщины индикатора фокуса.
Кому это важно
  • Все пользователи клавиатуры — люди с особенностями моторики, продвинутые пользователи.
  • Люди с когнитивными особенностями, у которых небольшой объём рабочей памяти или они легко отвлекаются и забывают на каком элементе остановились.
Как избежать барьер
За выполнением критерия в первую очередь должны следить дизайнеры. Хорошо проработать заранее стили фокуса для разных интерактивных элементов с учётом их типа, цветовой темы и так далее.
Всегда можно оставить браузерные стили фокуса по умолчанию, но не во всех браузерах они заметные. Если в дизайн-системе есть элементы того же цвета, что браузерные стили по умолчанию, тогда они вообще могут слиться друг с другом.
У разработчиков много способов задать стили для :focus или :focus-visible. Например, с помощью свойств outline, border, box-shadow, text-decoration или background. Подробнее про их плюсы и минусы почитайте в статье «Developing a focus style for a themable design system».
Примеры соответствия критерию
  • Когда ссылка в фокусе, вокруг неё появляется сплошная чёрная рамка шириной два (2) пикселя, которая полностью обводит ссылку со всех сторон. Фон страницы при этом светло-серый.
  • При фокусе на кнопке вокруг неё на небольшом расстоянии появляется сплошная тёмно-синяя рамка толщиной три (3) пикселя. Она достаточно контрастная по отношению к фону страницы.
На сайте сервиса для тестирования Fable используют несколько способов выделения элементов при фокусе. У текстовых ссылок меняется фоновый цвет и цвет текста. В неактивном состоянии ссылки голубого цвета, в фокусе их фон становится голубым, а цвет текста — белым. Нетекстовая ссылка с логотипом при фокусе обводится синей рамкой толщиной в три (3) пикселя.
Кнопки с белым фоном при фокусе обводятся рамкой внутри, толщина которой тоже три (3) пикселя. Кнопки с розовым фоном при фокусе меняют свой фон на белый, они обводятся розовой рамкой, а снаружи появляется ещё одна рамка такой же толщины.
Ссылки и кнопки в разных состояниях. Подробное описание перед картинкой.
Элементы интерфейса Fable.
На gov.uk также обнаружите несколько вариантов стилей для фокуса.
Ссылки по умолчанию синие с тонкой чертой такого же цвета под ними. Когда делаете на них фокус, они становятся чёрными, нижнее подчёркивание тоже становится чёрным и более жирным, а фон меняется на жёлтый.
Что касается текстовых полей, по умолчанию вокруг них тонкая чёрная рамка. При фокусе рамка становится более жирной, дополнительно вокруг неё появляется ещё одна жёлтого цвета.
У некоторых кнопок при фокусе фон с серого меняется на жёлтый, а более жирная нижняя граница увеличивается где-то на три (3) пикселя.
Поле поиска, ссылки и кнопки в состоянии фокуса и без. Подробное описание до картинки.
Интерфейс gov.uk.
Примеры барьеров
  • Вокруг названия вкладки при фокусе появляется пунктирная черта с точками, ширина которой 1 пиксель.
  • При фокусе внутри кнопки рядом с текстом появляется вертикальная черта толщиной 1 пиксель.
На сайте музея Ikea при фокусе на ссылках вокруг них появляется тонкая пунктирная рамка светло-серого цвета или тёмно-серого цвета в зависимости от цвета текста. Для неё используется свойство outline со значением 1px dotted currentColor.
Стили фокуса у ссылки из сообщения о кукиз, слайда из карусели, другой ссылки из футера и у логотипа сайта.
Интерактивные элементы на сайте музея Ikea.
Как тестировать
Тестируйте критерий смешанным способом, как и видимый фокус.
  • Найдите все интерактивные элементы с помощью Tab или скриптом.
  • Убедитесь, что у всех элементов индикатор фокуса соответствует требованиям.
Чтобы найти интерактивные элементы, используйте букмарклеты ANDI или Force Show Keyboard Focus. Другой способ — напишите свой небольшой скрипт и соберите интерактивные элементы в консоли в браузере.
document.addEventListener('focus', () => {
   console.log(document.activeElement);
 }, true);
Есть букмарклет Скотта О’Хары, который автоматически проходит через элементы и показывает их стили фокуса.
Наконец, если не можете определить на глаз толщину индикатора фокуса, можно посмотреть на его стили в инструменте разработчика в отдельной вкладке с ними. А соотношение контраста можно проверить, например, в WebAIM Contrast Checker.
Что почитать
Другие статьи
 Татьяна Фокина, 2021–2024
Разработано на 11ty, иконки с Lucide Нашли ошибку? Поделитесь ей на GitHub

\ No newline at end of file
diff --git a/ru/articles/wcag-focus-visible/index.html b/ru/articles/wcag-focus-visible/index.html
index da4ee45..0ce090e 100644
--- a/ru/articles/wcag-focus-visible/index.html
+++ b/ru/articles/wcag-focus-visible/index.html
@@ -21,7 +21,7 @@
 			},
 			"datePublished": "2022-12-18T00:00:00.000Z",
 			"dateModified": "2024-08-27T00:00:00.000Z"
-		}
 
Видимый фокус
  • WCAG
  • Дизайн
  • CSS
  • Клавиатура
 
 Обновлено: 
В этом посте из серии про разбор Руководств по доступности веб-контента (Web Content Accessibility Guidelines, коротко WCAG) расскажу про критерий 2.4.7: видимый фокус.
Критерий относится к принципу управляемости и к руководству про доступность с клавиатуры. Во WCAG 2.1 это критерий уровня AA. Во WCAG 2.2 уровень изменится на A.
Коротко о критерии
У интерфейса, с которым можно взаимодействовать с помощью клавиатуры, должен быть как минимум один способ работы с видимым индикатором фокуса (focus indicator).
Подробнее
Звучит сложно, но на самом деле всё не так страшно. У интерактивных элементов должны быть видимые стили фокуса, когда пользователь взаимодействует с ними. Например, у кнопок, ссылок или полей форм. Так что, в критерии нет указания на то, что, при взаимодействии с элементами с помощью мыши, фокус тоже должен быть обязательно виден.
Рекомендации по внешнему виду фокуса собраны в 2.4.11: внешний вид фокуса. Это новый критерий, который появится во WCAG 2.2. Однако, если фокус совсем незаметный, это считается нарушением критерия про видимый фокус. Например, когда рамка фокуса сливается с фоном кнопки или она тонкая и неконтрастная.
Другие требования к фокусу:
  • он не должен исчезать через какое-то время сам по себе;
  • стили элементов без фокуса не должны быть похожи на стили фокуса.
Хотя критерий этого не требует, следите за тем, чтобы у неактивных интерактивных элементов не было стилей фокуса. Например, в формах часто нельзя нажать на кнопку пока не заполнишь все нужные поля.
Кому это важно
  • Все пользователи клавиатуры — люди с особенностями моторики, продвинутые пользователи.
  • Люди с когнитивными особенностями, у которых небольшой объём кратковременной памяти. Они легко отвлекаются и быстрее забывают на каком элементе остановились.
Как избежать барьер
За стили фокуса отвечают дизайнеры и разработчики.
Дизайнеры могут проработать в дизайн-системе все состояния интерактивных элементов заранее.
Разработчиком достаточно не отменять стили фокуса по умолчанию:
a:focus {
+		}
 
Видимый фокус
  • WCAG
  • Дизайн
  • CSS
  • Клавиатура
 
 Обновлено: 
В этом посте из серии про разбор Руководств по доступности веб-контента (Web Content Accessibility Guidelines, коротко WCAG) расскажу про критерий 2.4.7: видимый фокус.
Критерий относится к принципу управляемости и к руководству про доступность с клавиатуры. Во WCAG 2.1 это критерий уровня AA. Во WCAG 2.2 уровень изменится на A.
Коротко о критерии
У интерфейса, с которым можно взаимодействовать с помощью клавиатуры, должен быть как минимум один способ работы с видимым индикатором фокуса (focus indicator).
Подробнее
Звучит сложно, но на самом деле всё не так страшно. У интерактивных элементов должны быть видимые стили фокуса, когда пользователь взаимодействует с ними. Например, у кнопок, ссылок или полей форм. Так что, в критерии нет указания на то, что, при взаимодействии с элементами с помощью мыши, фокус тоже должен быть обязательно виден.
Рекомендации по внешнему виду фокуса собраны в 2.4.11: внешний вид фокуса. Это новый критерий, который появится во WCAG 2.2. Однако, если фокус совсем незаметный, это считается нарушением критерия про видимый фокус. Например, когда рамка фокуса сливается с фоном кнопки или она тонкая и неконтрастная.
Другие требования к фокусу:
  • он не должен исчезать через какое-то время сам по себе;
  • стили элементов без фокуса не должны быть похожи на стили фокуса.
Хотя критерий этого не требует, следите за тем, чтобы у неактивных интерактивных элементов не было стилей фокуса. Например, в формах часто нельзя нажать на кнопку пока не заполнишь все нужные поля.
Кому это важно
  • Все пользователи клавиатуры — люди с особенностями моторики, продвинутые пользователи.
  • Люди с когнитивными особенностями, у которых небольшой объём кратковременной памяти. Они легко отвлекаются и быстрее забывают на каком элементе остановились.
Как избежать барьер
За стили фокуса отвечают дизайнеры и разработчики.
Дизайнеры могут проработать в дизайн-системе все состояния интерактивных элементов заранее.
Разработчиком достаточно не отменять стили фокуса по умолчанию:
a:focus {
   outline: 0;
 }
 
diff --git a/ru/articles/wcag-info-and-relationships/index.html b/ru/articles/wcag-info-and-relationships/index.html
index 2d129d1..ff43f7a 100644
--- a/ru/articles/wcag-info-and-relationships/index.html
+++ b/ru/articles/wcag-info-and-relationships/index.html
@@ -21,4 +21,4 @@
 			},
 			"datePublished": "2023-01-17T00:00:00.000Z",
 			"dateModified": "2024-09-02T00:00:00.000Z"
-		}
 
Информация и взаимосвязи
  • WCAG
  • HTML
  • CSS
  • ARIA
 
 Обновлено: 
Продолжаю разбирать Руководства по доступности веб-контента (Web Content Accessibility Guidelines, коротко WCAG). Сегодня расскажу про критерий 1.3.1: информация и взаимосвязи.
Это базовый критерий уровня A, который относится к принципу воспринимаемости и к руководству про адаптируемость.
Коротко о критерии
Информация, структура и отношения между элементами, которые видны визуально, также должны быть определены программно или доступны в виде текста.
Подробнее
Страницы и контент на страницах должны быть доступны в разных форматах представления — визуальном, аудиальном и любом другом. В этом критерий про информацию и взаимосвязь пересекается с одним из принципов универсального дизайна про равенство в использовании.
«Программно определённый» (programmatically determined) означает, что HTML и дополнительная ARIA-разметка используются правильно и отражают роль элемента, его свойства и связи с другими элементами. Критерий просит обозначать функции и роли элементов не только визуально, но и на уровне кода.
К примеру, визуально заголовки крупнее остального текста и часто выделены жирным начертанием. В коде то же самое обозначают теги <h1>, <h2>, <h3> и так далее. Параграфы содержат несколько предложений и между ними есть отступы. На уровне кода это отражает тег <p>. Обязательное для заполнения поле принято обозначать астериском (*). Рядом с ним можно подписать, что оно обязательное. Новое сообщение приходит со звуковым оповещением. Хорошо дополнить его ещё и текстовым уведомлением и сделать эту область изменяющейся (live region).
Из-за того, что критерий связан с разметкой и затрагивает много элементов на страницах, он довольно часто нарушается. По статистике Intopia эта ошибка в 2022 году обнаружена в 95 % аудитов и составляет 14 % от всех проблем с доступностью.
Кому это важно
  • Пользователи скринридеров, которые слушают интерфейсы. В первую очередь это люди со слепотой.
  • Пользователи дисплеев Брайля.
  • Пользователи с когнитивными особенностями, которые используют расширения для изменения стилей или режимы чтения в браузерах.
Как избежать барьер
Так как критерий про информацию и взаимосвязи связан с разметкой, в основном за его соблюдением должны следить разработчики.
Большую часть проблем решают семантические теги для структуры страницы и для отдельных элементов. Например, <header>, <main>, <footer>, <h1>–<h6>, <button>, <a>, <table> и многие другие. Кстати, у W3C есть хорошее руководство по таблицам.
Также следите за тем, чтобы разметка была валидной, id на странице не повторялись и были связаны с нужными элементами там, где требуется.
Обращайте внимание на групповые элементы. К примеру, если есть несколько связанных чекбоксов, хорошо обернуть их в <fieldset> и задать группе имя в <legend>.
Про ARIA думайте только в случае, когда возможностей HTML не хватает. Например, для заголовков в первую очередь используйте теги от <h1> до <h6>, а не role="heading" с нужным значением aria-level. Если решили использовать ARIA, всегда уточняйте какие атрибуты обязательно нужно использовать с ролями и какая их поддерживают вспомогательные технологии и браузеры.
Хороший повод использовать возможности ARIA — видимые заголовки для ориентиров. Это блоки страницы, по которым могут перемещаться пользователи скринридеров. К примеру, <header> и <footer>. Свяжите заголовок и ориентир с помощью aria-labelledby. Тогда у ориентиров появятся названия, а пользователям будет проще по ним перемещаться.
Примеры соответствия критерию
  • У обязательных полей в форме есть астериксы: «Перед формой пояснение «Обязательно заполните поля со звёздочкой (*)».
  • На странице текст «История происхождения вида». Он больше остального текста, выделен жирным начертанием. В разметке это <h2>.
  • Элемент с текстом «Отправить» выглядит как кнопка и отправляет сообщение в чат. В разметке для него используют тег <button>.
  • На странице боковое меню с заголовком «Похожие исполнители». В коде это <aside>, внутри которого есть <h2>. <aside> связан с <h2> с помощью aria-labelledby.
  • На странице, которая была свёрстана в 2001, таблица используется для раскладки, а не для данных. У неё сброшена табличная семантика с помощью role="presentation".
  • Текст из нескольких пунктов с буллитами, который похож на список. В разметке это <ul> с несколькими вложенными в него <li>.
Примеры барьеров
  • Текст «О нашей замечательной компании» выглядит как заголовок. Он расположен на отдельной строке, больше остального текста и выделен жирным начертанием. В коде для него используют тег <p> вместо <h1>.
  • Заголовок <h1> находится в кнопке <button>.
  • Элемент с текстом «Список товаров для дома» внешне выглядит и ведёт себя как ссылка, но в разметке это просто <span> с onclick="location.href='newpage.html'" без роли ссылки.
  • Текст расположен в двух колонках благодаря нескольким пробелам между словами, а не с помощью CSS.
  • В разделе отзывов есть карточки с текстом отзывов и именами людей, которые их оставили. Имя добавлено в карточку через псевдоэлемент ::before, хотя это не декоративный контент.
  • <table> используется на странице для раскладки, а не для данных. При этом табличная семантика не сброшена с помощью role="presentation", в таблице есть <th>.
  • Для таблицы с данными используют тег <table>, но внутри нарушена правильная иерархия элементов. Теги <tr> обёрнуты в <td>.
  • На странице есть двe кнопки, которые открывают выпадающие меню. Обе кнопки связаны с меню с помощью aria-controls и id, однако в случае обоих меню у них одинаковое значение id — dropdown-1.
  • Перед текстовым полем расположен лейбл «Дополнительные комментарии к заказу». У тега <label> нет атрибута for, хотя у <textfield> есть id.
  • На странице есть текст с круглыми буллитами. На самом деле это несколько параграфов <p> с символом буллита в начале — ∙.
  • Группа чекбоксов касается размера пиццы. Они не объединены в коде и у них нет связанного с ними общего названия группы.
На главной Apple Store есть большие разделы с заголовками. Например, «Help is here. Whenever and however you need it» («Помощь рядом. Когда и каким бы образом она ни была нужна»). Оба предложения находятся на отдельной строке, они одинакового размера и расположены друг за другом. Единственное различие — первое предложение тёмно-серого цвета, а второе светло-серого. В коде только «Help is here» — это <h2>. Второе предложение обёрнуто в <span>, который расположен рядом с <h2>.
Открыт интрумент для тестирования WAVE. Курсор наведён на заголовок. Первое предложение «Помощь рядом» из заголовка выделено красной пунктирной рамкой, над ним тултип с текстом «Заголовок второго уровня».
Один из заголовков второго уровня на главной Apple Store.
Ещё на сайте есть элемент, который выглядит как карточка-ссылка. Возьмём карточку с текстом «Enjoy two-hour delivery from an Apple Store, free delivery, or easy pickup» («Насладись двухчасовой доставкой из Apple Store, бесплатная доставка и простой самовывоз»).
Визуально это выглядит как параграф текста, перед которым салатовая иконка с грузовиком. Некоторые ключевые слова выделены таким же салатовым цветом — «two-hour delivery», «free delivery» и «easy pickup». В коде весь текст обёрнут в <p>, который вложен внутрь <a>.
Курсор в виде руки с протянутым указательным пальцем наведён на прямоугольный блок со скруглёнными краями, белым фоном и небольшой серой тенью. Внутри блока иконка с грузовиком и серый текст с несколькими выделенными словами.
Карточка на главной Apple Store.
Этот элемент нарушает и другие критерии. По названию ссылок не понятно, куда они ведут, а ещё на самом деле этот элемент открывает модальное окно на той же самой странице.
Как тестировать
Протестировать критерий про информацию и взаимосвязи поможет смешанное тестирование.
  • Откройте нужную страницу и проверьте её структуру. Какие на ней есть ориентиры, совпадает ли визуальное представление заголовков, списков, параграфов и других похожих элементов с представлением в коде.
  • Проверьте другие элементы, которые не связаны со структурой. Например, ссылки, кнопки, формы и т. д.
  • Если есть ARIA-разметка, насколько она корректна. Совпадают ли явно заданные роли с функциями и внешним видом элементов, правильно ли используются ARIA-атрибуты.
Проверить автоматически основную структуру страниц и разметку в целом помогут:
Ещё можно посмотреть вручную код в инструменте разработчика в браузере или отключить временно стили на странице. Крайне полезно также послушать страницу со скринридером.
Что почитать
Другие статьи
 Татьяна Фокина, 2021–2024
Разработано на 11ty, иконки с Lucide Нашли ошибку? Поделитесь ей на GitHub

\ No newline at end of file
+		}
 
Информация и взаимосвязи
  • WCAG
  • HTML
  • CSS
  • ARIA
 
 Обновлено: 
Продолжаю разбирать Руководства по доступности веб-контента (Web Content Accessibility Guidelines, коротко WCAG). Сегодня расскажу про критерий 1.3.1: информация и взаимосвязи.
Это базовый критерий уровня A, который относится к принципу воспринимаемости и к руководству про адаптируемость.
Коротко о критерии
Информация, структура и отношения между элементами, которые видны визуально, также должны быть определены программно или доступны в виде текста.
Подробнее
Страницы и контент на страницах должны быть доступны в разных форматах представления — визуальном, аудиальном и любом другом. В этом критерий про информацию и взаимосвязь пересекается с одним из принципов универсального дизайна про равенство в использовании.
«Программно определённый» (programmatically determined) означает, что HTML и дополнительная ARIA-разметка используются правильно и отражают роль элемента, его свойства и связи с другими элементами. Критерий просит обозначать функции и роли элементов не только визуально, но и на уровне кода.
К примеру, визуально заголовки крупнее остального текста и часто выделены жирным начертанием. В коде то же самое обозначают теги <h1>, <h2>, <h3> и так далее. Параграфы содержат несколько предложений и между ними есть отступы. На уровне кода это отражает тег <p>. Обязательное для заполнения поле принято обозначать астериском (*). Рядом с ним можно подписать, что оно обязательное. Новое сообщение приходит со звуковым оповещением. Хорошо дополнить его ещё и текстовым уведомлением и сделать эту область изменяющейся (live region).
Из-за того, что критерий связан с разметкой и затрагивает много элементов на страницах, он довольно часто нарушается. По статистике Intopia эта ошибка в 2022 году обнаружена в 95 % аудитов и составляет 14 % от всех проблем с доступностью.
Кому это важно
  • Пользователи скринридеров, которые слушают интерфейсы. В первую очередь это люди со слепотой.
  • Пользователи дисплеев Брайля.
  • Пользователи с когнитивными особенностями, которые используют расширения для изменения стилей или режимы чтения в браузерах.
Как избежать барьер
Так как критерий про информацию и взаимосвязи связан с разметкой, в основном за его соблюдением должны следить разработчики.
Большую часть проблем решают семантические теги для структуры страницы и для отдельных элементов. Например, <header>, <main>, <footer>, <h1>–<h6>, <button>, <a>, <table> и многие другие. Кстати, у W3C есть хорошее руководство по таблицам.
Также следите за тем, чтобы разметка была валидной, id на странице не повторялись и были связаны с нужными элементами там, где требуется.
Обращайте внимание на групповые элементы. К примеру, если есть несколько связанных чекбоксов, хорошо обернуть их в <fieldset> и задать группе имя в <legend>.
Про ARIA думайте только в случае, когда возможностей HTML не хватает. Например, для заголовков в первую очередь используйте теги от <h1> до <h6>, а не role="heading" с нужным значением aria-level. Если решили использовать ARIA, всегда уточняйте какие атрибуты обязательно нужно использовать с ролями и какая их поддерживают вспомогательные технологии и браузеры.
Хороший повод использовать возможности ARIA — видимые заголовки для ориентиров. Это блоки страницы, по которым могут перемещаться пользователи скринридеров. К примеру, <header> и <footer>. Свяжите заголовок и ориентир с помощью aria-labelledby. Тогда у ориентиров появятся названия, а пользователям будет проще по ним перемещаться.
Примеры соответствия критерию
  • У обязательных полей в форме есть астериксы: «Перед формой пояснение «Обязательно заполните поля со звёздочкой (*)».
  • На странице текст «История происхождения вида». Он больше остального текста, выделен жирным начертанием. В разметке это <h2>.
  • Элемент с текстом «Отправить» выглядит как кнопка и отправляет сообщение в чат. В разметке для него используют тег <button>.
  • На странице боковое меню с заголовком «Похожие исполнители». В коде это <aside>, внутри которого есть <h2>. <aside> связан с <h2> с помощью aria-labelledby.
  • На странице, которая была свёрстана в 2001, таблица используется для раскладки, а не для данных. У неё сброшена табличная семантика с помощью role="presentation".
  • Текст из нескольких пунктов с буллитами, который похож на список. В разметке это <ul> с несколькими вложенными в него <li>.
Примеры барьеров
  • Текст «О нашей замечательной компании» выглядит как заголовок. Он расположен на отдельной строке, больше остального текста и выделен жирным начертанием. В коде для него используют тег <p> вместо <h1>.
  • Заголовок <h1> находится в кнопке <button>.
  • Элемент с текстом «Список товаров для дома» внешне выглядит и ведёт себя как ссылка, но в разметке это просто <span> с onclick="location.href='newpage.html'" без роли ссылки.
  • Текст расположен в двух колонках благодаря нескольким пробелам между словами, а не с помощью CSS.
  • В разделе отзывов есть карточки с текстом отзывов и именами людей, которые их оставили. Имя добавлено в карточку через псевдоэлемент ::before, хотя это не декоративный контент.
  • <table> используется на странице для раскладки, а не для данных. При этом табличная семантика не сброшена с помощью role="presentation", в таблице есть <th>.
  • Для таблицы с данными используют тег <table>, но внутри нарушена правильная иерархия элементов. Теги <tr> обёрнуты в <td>.
  • На странице есть двe кнопки, которые открывают выпадающие меню. Обе кнопки связаны с меню с помощью aria-controls и id, однако в случае обоих меню у них одинаковое значение id — dropdown-1.
  • Перед текстовым полем расположен лейбл «Дополнительные комментарии к заказу». У тега <label> нет атрибута for, хотя у <textfield> есть id.
  • На странице есть текст с круглыми буллитами. На самом деле это несколько параграфов <p> с символом буллита в начале — ∙.
  • Группа чекбоксов касается размера пиццы. Они не объединены в коде и у них нет связанного с ними общего названия группы.
На главной Apple Store есть большие разделы с заголовками. Например, «Help is here. Whenever and however you need it» («Помощь рядом. Когда и каким бы образом она ни была нужна»). Оба предложения находятся на отдельной строке, они одинакового размера и расположены друг за другом. Единственное различие — первое предложение тёмно-серого цвета, а второе светло-серого. В коде только «Help is here» — это <h2>. Второе предложение обёрнуто в <span>, который расположен рядом с <h2>.
Открыт интрумент для тестирования WAVE. Курсор наведён на заголовок. Первое предложение «Помощь рядом» из заголовка выделено красной пунктирной рамкой, над ним тултип с текстом «Заголовок второго уровня».
Один из заголовков второго уровня на главной Apple Store.
Ещё на сайте есть элемент, который выглядит как карточка-ссылка. Возьмём карточку с текстом «Enjoy two-hour delivery from an Apple Store, free delivery, or easy pickup» («Насладись двухчасовой доставкой из Apple Store, бесплатная доставка и простой самовывоз»).
Визуально это выглядит как параграф текста, перед которым салатовая иконка с грузовиком. Некоторые ключевые слова выделены таким же салатовым цветом — «two-hour delivery», «free delivery» и «easy pickup». В коде весь текст обёрнут в <p>, который вложен внутрь <a>.
Курсор в виде руки с протянутым указательным пальцем наведён на прямоугольный блок со скруглёнными краями, белым фоном и небольшой серой тенью. Внутри блока иконка с грузовиком и серый текст с несколькими выделенными словами.
Карточка на главной Apple Store.
Этот элемент нарушает и другие критерии. По названию ссылок не понятно, куда они ведут, а ещё на самом деле этот элемент открывает модальное окно на той же самой странице.
Как тестировать
Протестировать критерий про информацию и взаимосвязи поможет смешанное тестирование.
  • Откройте нужную страницу и проверьте её структуру. Какие на ней есть ориентиры, совпадает ли визуальное представление заголовков, списков, параграфов и других похожих элементов с представлением в коде.
  • Проверьте другие элементы, которые не связаны со структурой. Например, ссылки, кнопки, формы и т. д.
  • Если есть ARIA-разметка, насколько она корректна. Совпадают ли явно заданные роли с функциями и внешним видом элементов, правильно ли используются ARIA-атрибуты.
Проверить автоматически основную структуру страниц и разметку в целом помогут:
Ещё можно посмотреть вручную код в инструменте разработчика в браузере или отключить временно стили на странице. Крайне полезно также послушать страницу со скринридером.
Что почитать
Другие статьи
 Татьяна Фокина, 2021–2024
Разработано на 11ty, иконки с Lucide Нашли ошибку? Поделитесь ей на GitHub

\ No newline at end of file
diff --git a/ru/articles/wcag-keyboard/index.html b/ru/articles/wcag-keyboard/index.html
index 662984f..f032f2a 100644
--- a/ru/articles/wcag-keyboard/index.html
+++ b/ru/articles/wcag-keyboard/index.html
@@ -21,4 +21,4 @@
 			},
 			"datePublished": "2023-03-07T00:00:00.000Z",
 			"dateModified": "2024-08-27T00:00:00.000Z"
-		}
 
Клавиатура
  • WCAG
  • Клавиатура
  • HTML
 
 Обновлено: 
В этом посте из серии про разбор Руководств по доступности веб-контента (Web Content Accessibility Guidelines, а коротко WCAG) расскажу про два принципа, связанных с клавиатурой.
Это критерии 2.1.1: клавиатура базового уровня A и 2.1.3: клавиатура (без исключений) самого высокого уровня AAA. Они связаны с принципом управляемости и руководством про доступность с клавиатуры.
Коротко о критериях
Пользователи клавиатуры имеют доступ ко всей функциональности интерфейса без специальных таймингов при нажатии на отдельные клавиши.
В критерии уровня A есть исключение — функции, которые требуют ввода, который зависит от траектории движения. Это могут быть симуляторы полётов, езды или программы для рисования, где для работы с некоторыми кистями нужна разная сила нажатия.
Критерий уровня AAA отличается от критерия минимального уровня только тем, что в нём нет исключений. Однако это не значит, что нужно пытаться сделать невозможное. Если разрабатываете приложение для рисования, то в каких-то случаях оно просто не будет соответствовать критерию уровня AAA.
Подробнее
Основная цель критерия — не забывать при разработке интерфейса учитывать потребности пользователей обычных и альтернативных клавиатур — экранных клавиатур, программ для sip-and-puff-технологий, для которых пользователи используют вдох и выдох, и других эмуляторов.
Какую именно функциональность должны поддерживать клавиатуры? Почти всю ту же, что и мышки. Например, выбор и перемещение элемента, изменение его размеров и так далее. Обратите внимание, что клавиши мыши не равны клавишам клавиатуры, так что в этом критерии вообще не идёт речь о мышках. При этом критерий не запрещает поддерживать другие устройства ввода.
Критерий также позволяет добавлять альтернативный способ для клавиатуры там, где никак не поддержать доступную функциональность для мышки. Например, как у драг-н-дроп элемента. В его случае можно добавить область для перетаскивания файла, с которым можно взаимодействовать только мышкой или касаниями, и отдельную кнопку для загрузки файла, которая доступна для клавиатуры.
Критерий не касается фокуса, только возможности взаимодействовать со всем интерактивным на странице с помощью клавиатуры. С фокусом связаны другие критерии — 2.4.7: видимый фокус и 2.4.11: внешний вид фокуса.
Кому это важно
Всем пользователям клавиатуры, но в особенности:
  • пользователям со слепотой;
  • слабовидящим пользователям;
  • пользователям с особенностями моторики, например, с тремором.
Как избежать барьер
В первую очередь барьеры для пользователей клавиатуры создают разработчики в момент, когда решают не использовать все возможности HTML для ссылок, кнопок и других интерактивных элементов.
Если нет возможности использовать семантические теги вроде <a>, <button> или <input>, кастомные интерактивные элементы должны полностью повторять встроенное в них поведение. С этим помогут разобраться JavaScript и глобальный HTML-атрибут tabindex. В качестве значения атрибута лучше указывать 0, а также избегать отрицательных и положительных значений больше нуля.
Примеры соответствия критериям
  • На странице с формой можно перемещаться между полями с помощью клавиатуры, вводить, копировать и вставлять в них данные, а также взаимодействовать так с кнопкой отправки.
  • В выпадающем меню для клавиатуры недоступна кнопка «Закрыть», но оно также закрывается при нажатии на Esc.
  • В слайдере недоступны с клавиатуры кнопки со стрелками вперёд и назад, но слайды можно перелистывать клавиатурными стрелками.
  • На сайте есть область для перетаскивания файла. Рядом с ней есть альтернативный способ загрузки файла в виде кнопки, с которой можно взаимодействовать с клавиатуры.
  • В веб-приложении для рисования можно создавать объекты, изменять их размеры, цвета и перемещать с помощью клавиатуры.
  • С элементом для выбора даты из календаря можно взаимодействовать только с мышкой, при этом в поле можно ввести дату вручную с клавиатуры.
Примеры барьеров
  • На сайте для ссылок и кнопок используют <div> и <span>, у них нет атрибутов tabindex со значением 0. Из-за этого пользователи не могут взаимодействовать с элементами с клавиатуры.
  • На странице есть область для загрузки файла, но с ней можно взаимодействовать только с помощью мышки или касаний. На странице нет альтернативного способа загрузить файл без перетаскивания.
Как тестировать
Протестировать оба критерия можно только ручным способом. Для этого проверьте всю функциональность интерфейса с помощью клавиатуры.
  • Пройдитесь с помощью Tab по всем интерактивным элементам.
  • Повзаимодействуйте с элементами с помощью Enter и пробела или других клавиш, если они поддерживаются.
  • Если элемент прокручивается, попробуйте это сделать с помощью стрелок вверх, вниз, вправо и влево.
  • Проверьте, есть ли альтернативный способ взаимодействия с элементом с помощью клавиатуры.
Что почитать
Другие статьи
 Татьяна Фокина, 2021–2024
Разработано на 11ty, иконки с Lucide Нашли ошибку? Поделитесь ей на GitHub

\ No newline at end of file
+		}
 
Клавиатура
  • WCAG
  • Клавиатура
  • HTML
 
 Обновлено: 
В этом посте из серии про разбор Руководств по доступности веб-контента (Web Content Accessibility Guidelines, а коротко WCAG) расскажу про два принципа, связанных с клавиатурой.
Это критерии 2.1.1: клавиатура базового уровня A и 2.1.3: клавиатура (без исключений) самого высокого уровня AAA. Они связаны с принципом управляемости и руководством про доступность с клавиатуры.
Коротко о критериях
Пользователи клавиатуры имеют доступ ко всей функциональности интерфейса без специальных таймингов при нажатии на отдельные клавиши.
В критерии уровня A есть исключение — функции, которые требуют ввода, который зависит от траектории движения. Это могут быть симуляторы полётов, езды или программы для рисования, где для работы с некоторыми кистями нужна разная сила нажатия.
Критерий уровня AAA отличается от критерия минимального уровня только тем, что в нём нет исключений. Однако это не значит, что нужно пытаться сделать невозможное. Если разрабатываете приложение для рисования, то в каких-то случаях оно просто не будет соответствовать критерию уровня AAA.
Подробнее
Основная цель критерия — не забывать при разработке интерфейса учитывать потребности пользователей обычных и альтернативных клавиатур — экранных клавиатур, программ для sip-and-puff-технологий, для которых пользователи используют вдох и выдох, и других эмуляторов.
Какую именно функциональность должны поддерживать клавиатуры? Почти всю ту же, что и мышки. Например, выбор и перемещение элемента, изменение его размеров и так далее. Обратите внимание, что клавиши мыши не равны клавишам клавиатуры, так что в этом критерии вообще не идёт речь о мышках. При этом критерий не запрещает поддерживать другие устройства ввода.
Критерий также позволяет добавлять альтернативный способ для клавиатуры там, где никак не поддержать доступную функциональность для мышки. Например, как у драг-н-дроп элемента. В его случае можно добавить область для перетаскивания файла, с которым можно взаимодействовать только мышкой или касаниями, и отдельную кнопку для загрузки файла, которая доступна для клавиатуры.
Критерий не касается фокуса, только возможности взаимодействовать со всем интерактивным на странице с помощью клавиатуры. С фокусом связаны другие критерии — 2.4.7: видимый фокус и 2.4.11: внешний вид фокуса.
Кому это важно
Всем пользователям клавиатуры, но в особенности:
  • пользователям со слепотой;
  • слабовидящим пользователям;
  • пользователям с особенностями моторики, например, с тремором.
Как избежать барьер
В первую очередь барьеры для пользователей клавиатуры создают разработчики в момент, когда решают не использовать все возможности HTML для ссылок, кнопок и других интерактивных элементов.
Если нет возможности использовать семантические теги вроде <a>, <button> или <input>, кастомные интерактивные элементы должны полностью повторять встроенное в них поведение. С этим помогут разобраться JavaScript и глобальный HTML-атрибут tabindex. В качестве значения атрибута лучше указывать 0, а также избегать отрицательных и положительных значений больше нуля.
Примеры соответствия критериям
  • На странице с формой можно перемещаться между полями с помощью клавиатуры, вводить, копировать и вставлять в них данные, а также взаимодействовать так с кнопкой отправки.
  • В выпадающем меню для клавиатуры недоступна кнопка «Закрыть», но оно также закрывается при нажатии на Esc.
  • В слайдере недоступны с клавиатуры кнопки со стрелками вперёд и назад, но слайды можно перелистывать клавиатурными стрелками.
  • На сайте есть область для перетаскивания файла. Рядом с ней есть альтернативный способ загрузки файла в виде кнопки, с которой можно взаимодействовать с клавиатуры.
  • В веб-приложении для рисования можно создавать объекты, изменять их размеры, цвета и перемещать с помощью клавиатуры.
  • С элементом для выбора даты из календаря можно взаимодействовать только с мышкой, при этом в поле можно ввести дату вручную с клавиатуры.
Примеры барьеров
  • На сайте для ссылок и кнопок используют <div> и <span>, у них нет атрибутов tabindex со значением 0. Из-за этого пользователи не могут взаимодействовать с элементами с клавиатуры.
  • На странице есть область для загрузки файла, но с ней можно взаимодействовать только с помощью мышки или касаний. На странице нет альтернативного способа загрузить файл без перетаскивания.
Как тестировать
Протестировать оба критерия можно только ручным способом. Для этого проверьте всю функциональность интерфейса с помощью клавиатуры.
  • Пройдитесь с помощью Tab по всем интерактивным элементам.
  • Повзаимодействуйте с элементами с помощью Enter и пробела или других клавиш, если они поддерживаются.
  • Если элемент прокручивается, попробуйте это сделать с помощью стрелок вверх, вниз, вправо и влево.
  • Проверьте, есть ли альтернативный способ взаимодействия с элементом с помощью клавиатуры.
Что почитать
Другие статьи
 Татьяна Фокина, 2021–2024
Разработано на 11ty, иконки с Lucide Нашли ошибку? Поделитесь ей на GitHub

\ No newline at end of file
diff --git a/ru/articles/wcag-non-text-content/index.html b/ru/articles/wcag-non-text-content/index.html
index 6820b39..bc8aec0 100644
--- a/ru/articles/wcag-non-text-content/index.html
+++ b/ru/articles/wcag-non-text-content/index.html
@@ -21,7 +21,7 @@
 			},
 			"datePublished": "2022-11-28T00:00:00.000Z",
 			"dateModified": "2022-11-28T00:00:00.000Z"
-		}
 
Нетекстовое содержимое
  • WCAG
  • HTML
  • ARIA
  • Анимация
  • Графика
  • Мультимедиа
 
В этом посте из серии про разбор Руководств по доступности веб-контента (Web Content Accessibility Guidelines, коротко WCAG) расскажу про самый первый критерий 1.1.1: нетекстовое содержимое.
Это базовый критерий уровня A, и он связан с принципом воспринимаемости и с руководством о текстовых альтернативах.
Коротко о критерии
У всего нетекстового содержимого есть текстовые альтернативы, которые описывают его или его цель.
Подробнее
Нетекстовое содержимое или нетекстовый контент — это содержимое, которое не состоит из текста на естественном языке или в котором не имеет значения последовательность символов из языка.
Чаще всего нетекстовое содержимое бывает таким:
  • изображения — фоновые и вставленные с помощью CSS, SVG, <img>;
  • иконки, включая те, что в кнопках и ссылках;
  • иконочные шрифты;
  • ASCII-графика (American Standard Code for Information Interchange Art), когда изображение складывается из знаков и глифов;
  • смайлики и эмодзи;
  • анимация;
  • видео и аудио;
  • капча (CAPTCHA).
Другое важное понятие — текстовая альтернатива (text alternative). Это текст, который описывает содержимое или функции нетекстового контента. На самом деле это не только альтернативное описание картинок из alt, но и любой другой текст, который программно определён (programmatically determinable) и программно связан (programmatically associated) с нетекстовым контентом. Например, если в кнопке есть иконка и мы задали ей название в aria-label. Так мы программно определили название кнопки и связали его с ней с помощью этого атрибута и его содержимого.
Давайте теперь разберёмся с тем, как добавить текстовые альтернативы к разным типам нетекстового содержимого.
Чаще всего, конечно, встречаются изображения. Они могут быть смысловыми и декоративными. Смысловые содержат важную информацию, о которой должен узнать пользователь. Декоративные нужны для того, чтобы страница выглядела привлекательнее и интереснее. Если их убрать со страницы, смысл другого содержимого не изменится и не потеряется.
Критерий 1.1.1 касается всех типов изображений. У недекоративных картинок должно быть альтернативное описание, а декоративные должны быть точно недоступны для вспомогательных технологий.
У кнопок, ссылок и других элементов управления с иконками должно быть имя. Имя — это краткое название элемента, которое обычно доступно только для пользователей вспомогательных технологий. В случае кнопки оно должно рассказывать о том, что делает кнопка, а с случае ссылки — куда она ведёт.
Иконочные шрифты в большинстве случаев лучше скрыть от вспомогательных технологий и добавить скрытую текстовую альтернативу.
Эмодзи поддерживаются лучше, чем текстовые смайлики. Так что лучше использовать их. Имейте в виду, что разные скринридеры могут по разному их зачитывать. Они берут текстовые альтернативы из своих таблиц с описанием эмодзи.
Что касается ASCII-графики и анимации, то их лучше подробнее описать в тексте и добавить краткое альтернативное описание с указанием того, что они были подробнее описаны до или после в тексте. Альтернативный вариант для ASCII-графики — сделать скриншот и описать её как любую другую картинку.
Видео и аудио согласно критерия должны быть описаны на странице. В этом описании можно рассказать кратко о том, что происходит в видео или о чём идёт речь в аудио. Особенно это важно в случае прямых трансляций без звука или только со звуком. Это может быть заголовок или параграф текста. Так пользователи поймут, стоит ли им начинать просмотр или прослушивание.
Капча — сложный элемент с точки зрения доступности. Она может усложнить жизнь не только ботам, но и людям. С капчами возникают трудности у многих категорий пользователей — людей со слепотой, глухотой, когнитивными особенностями. Самый надёжный способ — не использовать капчу вообще, а также воспользоваться reCAPTCHA v2 или похожим решением, с которой не надо взаимодействовать пользователям.
Другие способы сделать капчу более-менее доступной — использовать не только картинку, но и озвучивать её содержимое, предложить пользователям альтернативный способ подтверждения того, что они не роботы, а также кратко описать её цель в текстовой альтернативе.
Отдельно в критерии про текстовые альтернативы для нетекстового содержимого рассматриваются тесты и упражнения для проверки знаний. Например, в языковых тестах часто есть аудирование, когда нужно прослушать запись и ответить потом на вопросы. В таком случае в текстовой альтернативе должна быть описана цель этой записи, а не её содержимое. Иначе такое задание потеряет смысл.
Также на сайте может быть содержимое, которое обязательно нужно воспринимать именно визуально или на слух. Например, классическая музыка или картины. Для них можно добавить подробный текст и добавить краткую текстовую альтернативу.
Кому это важно
  • Все пользователи скринридеров и экранных луп, особенно люди со слепотой и слабовидящие.
  • Пользователи дисплеев Брайля.
  • Люди с глухотой и слабослышащие.
  • Люди с когнитивными особенностями, которым трудно понять смысл картинки или прочитать схему.
  • Люди, которым трудно воспринимать информацию на слух.
Также текстовые альтернативы помогают поисковым роботам и облегчают поиск по странице для пользователей.
Как избежать барьер
Барьер из-за отсутствия текстовой альтернативы для нетекстового содержимого возникает чаще всего на этапе создания контента и кода.
Если вы разработчик, то держите несколько советов по тому, как добавить текстовую альтернативу.
Для <img> добавьте:
  • атрибут alt с описанием;
  • aria-label для визуально скрытого имени, aria-labelledby для видимого имени, которое находится в другом элементе;
  • расширенное описание в aria-describedby или aria-details. В реальности aria-details пока не очень хорошо поддерживается.
<img
+		}
 
Нетекстовое содержимое
  • WCAG
  • HTML
  • ARIA
  • Анимация
  • Графика
  • Мультимедиа
 
В этом посте из серии про разбор Руководств по доступности веб-контента (Web Content Accessibility Guidelines, коротко WCAG) расскажу про самый первый критерий 1.1.1: нетекстовое содержимое.
Это базовый критерий уровня A, и он связан с принципом воспринимаемости и с руководством о текстовых альтернативах.
Коротко о критерии
У всего нетекстового содержимого есть текстовые альтернативы, которые описывают его или его цель.
Подробнее
Нетекстовое содержимое или нетекстовый контент — это содержимое, которое не состоит из текста на естественном языке или в котором не имеет значения последовательность символов из языка.
Чаще всего нетекстовое содержимое бывает таким:
  • изображения — фоновые и вставленные с помощью CSS, SVG, <img>;
  • иконки, включая те, что в кнопках и ссылках;
  • иконочные шрифты;
  • ASCII-графика (American Standard Code for Information Interchange Art), когда изображение складывается из знаков и глифов;
  • смайлики и эмодзи;
  • анимация;
  • видео и аудио;
  • капча (CAPTCHA).
Другое важное понятие — текстовая альтернатива (text alternative). Это текст, который описывает содержимое или функции нетекстового контента. На самом деле это не только альтернативное описание картинок из alt, но и любой другой текст, который программно определён (programmatically determinable) и программно связан (programmatically associated) с нетекстовым контентом. Например, если в кнопке есть иконка и мы задали ей название в aria-label. Так мы программно определили название кнопки и связали его с ней с помощью этого атрибута и его содержимого.
Давайте теперь разберёмся с тем, как добавить текстовые альтернативы к разным типам нетекстового содержимого.
Чаще всего, конечно, встречаются изображения. Они могут быть смысловыми и декоративными. Смысловые содержат важную информацию, о которой должен узнать пользователь. Декоративные нужны для того, чтобы страница выглядела привлекательнее и интереснее. Если их убрать со страницы, смысл другого содержимого не изменится и не потеряется.
Критерий 1.1.1 касается всех типов изображений. У недекоративных картинок должно быть альтернативное описание, а декоративные должны быть точно недоступны для вспомогательных технологий.
У кнопок, ссылок и других элементов управления с иконками должно быть имя. Имя — это краткое название элемента, которое обычно доступно только для пользователей вспомогательных технологий. В случае кнопки оно должно рассказывать о том, что делает кнопка, а с случае ссылки — куда она ведёт.
Иконочные шрифты в большинстве случаев лучше скрыть от вспомогательных технологий и добавить скрытую текстовую альтернативу.
Эмодзи поддерживаются лучше, чем текстовые смайлики. Так что лучше использовать их. Имейте в виду, что разные скринридеры могут по разному их зачитывать. Они берут текстовые альтернативы из своих таблиц с описанием эмодзи.
Что касается ASCII-графики и анимации, то их лучше подробнее описать в тексте и добавить краткое альтернативное описание с указанием того, что они были подробнее описаны до или после в тексте. Альтернативный вариант для ASCII-графики — сделать скриншот и описать её как любую другую картинку.
Видео и аудио согласно критерия должны быть описаны на странице. В этом описании можно рассказать кратко о том, что происходит в видео или о чём идёт речь в аудио. Особенно это важно в случае прямых трансляций без звука или только со звуком. Это может быть заголовок или параграф текста. Так пользователи поймут, стоит ли им начинать просмотр или прослушивание.
Капча — сложный элемент с точки зрения доступности. Она может усложнить жизнь не только ботам, но и людям. С капчами возникают трудности у многих категорий пользователей — людей со слепотой, глухотой, когнитивными особенностями. Самый надёжный способ — не использовать капчу вообще, а также воспользоваться reCAPTCHA v2 или похожим решением, с которой не надо взаимодействовать пользователям.
Другие способы сделать капчу более-менее доступной — использовать не только картинку, но и озвучивать её содержимое, предложить пользователям альтернативный способ подтверждения того, что они не роботы, а также кратко описать её цель в текстовой альтернативе.
Отдельно в критерии про текстовые альтернативы для нетекстового содержимого рассматриваются тесты и упражнения для проверки знаний. Например, в языковых тестах часто есть аудирование, когда нужно прослушать запись и ответить потом на вопросы. В таком случае в текстовой альтернативе должна быть описана цель этой записи, а не её содержимое. Иначе такое задание потеряет смысл.
Также на сайте может быть содержимое, которое обязательно нужно воспринимать именно визуально или на слух. Например, классическая музыка или картины. Для них можно добавить подробный текст и добавить краткую текстовую альтернативу.
Кому это важно
  • Все пользователи скринридеров и экранных луп, особенно люди со слепотой и слабовидящие.
  • Пользователи дисплеев Брайля.
  • Люди с глухотой и слабослышащие.
  • Люди с когнитивными особенностями, которым трудно понять смысл картинки или прочитать схему.
  • Люди, которым трудно воспринимать информацию на слух.
Также текстовые альтернативы помогают поисковым роботам и облегчают поиск по странице для пользователей.
Как избежать барьер
Барьер из-за отсутствия текстовой альтернативы для нетекстового содержимого возникает чаще всего на этапе создания контента и кода.
Если вы разработчик, то держите несколько советов по тому, как добавить текстовую альтернативу.
Для <img> добавьте:
  • атрибут alt с описанием;
  • aria-label для визуально скрытого имени, aria-labelledby для видимого имени, которое находится в другом элементе;
  • расширенное описание в aria-describedby или aria-details. В реальности aria-details пока не очень хорошо поддерживается.
<img
     src="cute-dog.png"
     alt="Золотистый ретривер с красным ошейником лежит на лужайке.
     Он повёрнут вправо, положил голову на передние лапы и смотрит на
diff --git a/ru/articles/wcag-page-titled/index.html b/ru/articles/wcag-page-titled/index.html
index ec09562..701e77a 100644
--- a/ru/articles/wcag-page-titled/index.html
+++ b/ru/articles/wcag-page-titled/index.html
@@ -21,7 +21,7 @@
 			},
 			"datePublished": "2022-12-30T00:00:00.000Z",
 			"dateModified": "2024-08-27T00:00:00.000Z"
-		}
 
Название страницы
  • WCAG
  • HTML
  • Контент
 
 Обновлено: 
В этом посте из серии про разбор Руководств по доступности веб-контента (Web Content Accessibility Guidelines, коротко WCAG) расскажу про критерий 2.4.2: название страницы.
Это базовый критерий уровня A, который относится к принципу управляемости и к руководству про навигируемость.
Коротко о критерии
У страницы должно быть название, которое описывает её цель или тему.
Подробнее
Название или заголовок страницы — это то, что пользователи видят или слышат, когда взаимодействуют со вкладкой в браузере или со ссылкой в поисковой выдаче. Это один из факторов ранжирования, так что здесь доступность пересекается с SEO.
Конкретно критерий касается атрибута <title> и его содержимого.
Доступные названия кратко и чётко описывают основные темы или цели страниц и документов. Так пользователи быстрее узнают об их содержании и им проще ориентироваться по сайту.
В критерии несколько конкретных требований к названию страниц:
  • Чёткое, понятное и хорошо описывает тему страницы или документа. Лучше использовать простой язык и избегать жаргонизмов и сложных терминов.
  • Динамически меняется вместе с контентом страницы, когда изменяется её тема или цель.
За пределами WCAG есть несколько других хороших практик для названий:
  • Используйте не больше 60 символов. Чем короче название, тем лучше.
  • Не теряет смысл вне контекста страницы.
  • Уникальное и не повторяет полностью названия других страниц.
  • Если используете название сайта, сервиса или компании, перед ними должно идти описание страницы.
  • Не повторяйте много раз одни и те же разделители в одном названии и не используйте их в декоративных целях. Например, несколько тильд (~~~) или плюсов (+++) подряд.
  • Старайтесь придерживаться одинаковых паттернов. Например, если решили использовать длинное тире, используйте его везде.
В названиях страниц можно использовать 1–2 ключевых слова. Если их не будет, это никак не повлияет на доступность или результаты в поисковой выдаче.
Проще всего повторять в <title> содержимое <h1>, но это тоже не обязательное правило. К примеру, в основном заголовке на странице может быть приветствие, которое лучше не использовать в названии.
Название главной страницы не обязательно должно чётко описывать содержимое, так что это исключение из критерия. Для таких страниц можно использовать только название компании, сервиса или сайта.
Когда ссылаетесь на страницу сайта, можно повторить или слегка изменить название страницы в тексте ссылки.
Кому это важно
  • Все пользователи, особенно когда у них в браузере открыто несколько вкладок.
  • Пользователи скринридеров. Благодаря названиям страниц во вкладках им проще перемещаться между ними.
  • Люди с когнитивными особенностями. Особенно те, у кого небольшой объём рабочей памяти, и они легко забывают, на какой вкладке были до этого.
  • Пользователи с особенностями моторики, которые управляют интерфейсом с помощью голоса.
Как избежать барьер
Над названием страниц работают люди, которые создают контент, дизайн или код.
Чтобы выполнить критерий, обязательно используйте тег <title> с содержимым, которое кратко и чётко описывает страницу. Тег размещают внутри <head>.
<!doctype html>
+		}
 
Название страницы
  • WCAG
  • HTML
  • Контент
 
 Обновлено: 
В этом посте из серии про разбор Руководств по доступности веб-контента (Web Content Accessibility Guidelines, коротко WCAG) расскажу про критерий 2.4.2: название страницы.
Это базовый критерий уровня A, который относится к принципу управляемости и к руководству про навигируемость.
Коротко о критерии
У страницы должно быть название, которое описывает её цель или тему.
Подробнее
Название или заголовок страницы — это то, что пользователи видят или слышат, когда взаимодействуют со вкладкой в браузере или со ссылкой в поисковой выдаче. Это один из факторов ранжирования, так что здесь доступность пересекается с SEO.
Конкретно критерий касается атрибута <title> и его содержимого.
Доступные названия кратко и чётко описывают основные темы или цели страниц и документов. Так пользователи быстрее узнают об их содержании и им проще ориентироваться по сайту.
В критерии несколько конкретных требований к названию страниц:
  • Чёткое, понятное и хорошо описывает тему страницы или документа. Лучше использовать простой язык и избегать жаргонизмов и сложных терминов.
  • Динамически меняется вместе с контентом страницы, когда изменяется её тема или цель.
За пределами WCAG есть несколько других хороших практик для названий:
  • Используйте не больше 60 символов. Чем короче название, тем лучше.
  • Не теряет смысл вне контекста страницы.
  • Уникальное и не повторяет полностью названия других страниц.
  • Если используете название сайта, сервиса или компании, перед ними должно идти описание страницы.
  • Не повторяйте много раз одни и те же разделители в одном названии и не используйте их в декоративных целях. Например, несколько тильд (~~~) или плюсов (+++) подряд.
  • Старайтесь придерживаться одинаковых паттернов. Например, если решили использовать длинное тире, используйте его везде.
В названиях страниц можно использовать 1–2 ключевых слова. Если их не будет, это никак не повлияет на доступность или результаты в поисковой выдаче.
Проще всего повторять в <title> содержимое <h1>, но это тоже не обязательное правило. К примеру, в основном заголовке на странице может быть приветствие, которое лучше не использовать в названии.
Название главной страницы не обязательно должно чётко описывать содержимое, так что это исключение из критерия. Для таких страниц можно использовать только название компании, сервиса или сайта.
Когда ссылаетесь на страницу сайта, можно повторить или слегка изменить название страницы в тексте ссылки.
Кому это важно
  • Все пользователи, особенно когда у них в браузере открыто несколько вкладок.
  • Пользователи скринридеров. Благодаря названиям страниц во вкладках им проще перемещаться между ними.
  • Люди с когнитивными особенностями. Особенно те, у кого небольшой объём рабочей памяти, и они легко забывают, на какой вкладке были до этого.
  • Пользователи с особенностями моторики, которые управляют интерфейсом с помощью голоса.
Как избежать барьер
Над названием страниц работают люди, которые создают контент, дизайн или код.
Чтобы выполнить критерий, обязательно используйте тег <title> с содержимым, которое кратко и чётко описывает страницу. Тег размещают внутри <head>.
<!doctype html>
 <html lang="nb-NO">
   <head>
     <title>Litteratur – NRK Kultur</title>
diff --git a/ru/articles/wcag-sensory-characteristics/index.html b/ru/articles/wcag-sensory-characteristics/index.html
index b43121d..ab49a81 100644
--- a/ru/articles/wcag-sensory-characteristics/index.html
+++ b/ru/articles/wcag-sensory-characteristics/index.html
@@ -21,4 +21,4 @@
 			},
 			"datePublished": "2022-11-07T00:00:00.000Z",
 			"dateModified": "2024-09-03T00:00:00.000Z"
-		}
 
Сенсорные характеристики
  • WCAG
  • Контент
  • Дизайн
 
 Обновлено: 
В этом посте из серии про разбор Руководств по доступности веб-контента (Web Content Accessibility Guidelines, коротко WCAG) расскажу про критерий 1.3.3: сенсорные характеристики.
Это базовый критерий уровня A, он связан с принципом воспринимаемости и с различимостью содержимого.
Коротко о критерии
Инструкции о том, как взаимодействовать с чем-то на странице, не зависят от сенсорных характеристик элемента — формы, размера, цвета, места, звука и прочего.
Подробнее
Критерий относится к любым инструкциям на сайтах. Это могут быть инструкции к целым формам, звуковые оповещения, подсказки к полям, а может быть просто текст на странице с анонсом новой фичи и рассказом о том, как её использовать.
Когда описываете работу с чем-то, расскажите не только о внешнем виде элемента, а ещё про его название и функции. Так что, принцип подразумевает, что у кнопки или ссылки есть название. Лучше делать его видимым, хотя WCAG разрешает добавлять для кнопок визуально скрытые имена. Они доступны только пользователям вспомогательных технологий.
К примеру, когда пользователь скринридера услышит «Найдите круглую синюю кнопку в левом углу экрана», это не поможет ему найти эту кнопку. Скринридеры не рассказывают о цветах и других стилях элементов, а ещё сложно понять на слух, где право и лево на сайте.
Ещё внешний вид и расположение элементов могут отличаться в зависимости от темы на сайте, размера экрана и при разном освещении и яркости.
Чтобы инструкция про кнопку стала понятной всем, можно рассказать чуть больше про неё: «Найдите круглую синюю кнопку с названием «Следующая страница» в левом углу экрана». Теперь пользователь скринридера знает её название и может найти в списке всех кнопок или перейти к ней без списка.
В инструкциях полезно описывать внешние характеристики элемента. Это помогает некоторым пользователям с когнитивными особенностями и нейроотличиями, так что критерий не призывает рассказывать только о названиях и функциях.
Критерий перекликается с одним из принципов универсального дизайна о легко воспринимаемой информации. Этот принцип требует использовать несколько каналов восприятия — визуальный, аудиальный, тактильный и вербальный.
Несколько примеров инструкций, в которых что-то пошло не так:
  • Больше информации найдёте справа.
  • Если кликните на стрелку, перейдёте к следующему шагу.
  • Важная информация выделена жёлтым цветом.
  • Кликните по круглой синей кнопке в верхнем правом углу.
Что касается «выше» и «ниже», всё зависит от контекста и языка. Пользователям может быть понятно, что содержимое находится до определённой точки или после неё.
Кому это важно
  • Пользователям со слепотой и слабовидящим, которые много полагаются на слух.
  • Пользователям с глухотой и слабослышащим, которым важно видеть содержимое.
  • Пользователям мобильных устройств. Расположение элементов на странице в мобильной версии сайта может отличаться от десктопной.
Как избежать барьер
Этот барьер обычно появляется на этапе информационного дизайна и написания текстов, поэтому хорошо заранее обращать внимание понятность и доступность инструкций.
Разработчики могут следить за названиями элементов в коде и давать кнопкам, ссылкам и другим элементам хотя бы визуально скрытые названия. Также хорошо использовать заголовки для разных частей страницы, например, для бокового меню или списков со ссылками.
Примеры соответствия критерию
  • В правой части страницы есть список ссылок на тарифные планы. В тексте сказано: «Выберите тарифный план из списка с заголовком «Наши тарифные планы». Он находится справа».
  • При заполнении поля появилась ошибка. В ней использована иконка с крестиком и текст «Вы неправильно заполнили поле. Рекомендуем формат месяц-дата-число».
На сайте Vimeo есть форма регистрации нового пользователя. Если ввёл неправильные данные в одно из полей, например, для почты, под ним появится текстовая ошибка «Введите правильный адрес электронной почты, пожалуйста». Неправильно заполненное поле при этом тоже визуально изменится. К нему добавится красная рамка и иконка с восклицательным знаком внутри.
Форма «Присоединиться к Vimeo». Выделено поле «Email», в него частично введён адрес «myemail@».
Форма регистрации на Vimeo.
Примеры барьеров
  • На сайте карусель с кнопками со стрелками влево и вправо. В инструкции на странице написано: «Для перехода к следующему товару нажмите на правую кнопку, для возврата — на левую кнопку».
  • На странице есть боковое меню со списком ссылок на другие статьи. В инструкции на странице сказано: «Другие статьи найдёте в боковом меню справа».
  • При заполнении поля появилась ошибка. В ней только иконка с крестиком без видимого или визуально скрытого текста.
  • Страница с тестом. Время для его прохождения ограничено. В инструкции перед тестом написано: «Когда время истечёт, вы услышите сигнал об этом».
  • На странице таблица с разноцветными строками. Под таблицей пояснение: «Зелёные строки в таблице означают прибыль компании в этом месяце, а красные — расходы».
В десктопной версии TikTok раньше была инструкция, как войти в личный аккаунт с помощью QR-кода. В инструкции был скриншот мобильного приложения и описание шагов. Первый — «откройте приложение TikTok на своём мобильном устройстве». Второй — «в профиле тапните…», и тут вместо текста иконка с человечком и крестиком. Последний шаг — «тапните…», и опять вместо строчки текста иконка с пунктирной рамкой и горизонтальной чертой по центру.
Модальное окно с заголовком «Залогиниться с помощью QR-кода».
Инструкция для входа в TikTok-аккаунт с помощью QR-кода.
Как тестировать
С поиском проблем с сенсорными характеристиками поможет только ручное тестирование.
  • Найдите страницы, где есть инструкции.
  • Убедитесь, что в них описан не только внешний вид элементов и их положение на странице.
Что почитать
Другие статьи
 Татьяна Фокина, 2021–2024
Разработано на 11ty, иконки с Lucide Нашли ошибку? Поделитесь ей на GitHub

\ No newline at end of file
+		}
 
Сенсорные характеристики
  • WCAG
  • Контент
  • Дизайн
 
 Обновлено: 
В этом посте из серии про разбор Руководств по доступности веб-контента (Web Content Accessibility Guidelines, коротко WCAG) расскажу про критерий 1.3.3: сенсорные характеристики.
Это базовый критерий уровня A, он связан с принципом воспринимаемости и с различимостью содержимого.
Коротко о критерии
Инструкции о том, как взаимодействовать с чем-то на странице, не зависят от сенсорных характеристик элемента — формы, размера, цвета, места, звука и прочего.
Подробнее
Критерий относится к любым инструкциям на сайтах. Это могут быть инструкции к целым формам, звуковые оповещения, подсказки к полям, а может быть просто текст на странице с анонсом новой фичи и рассказом о том, как её использовать.
Когда описываете работу с чем-то, расскажите не только о внешнем виде элемента, а ещё про его название и функции. Так что, принцип подразумевает, что у кнопки или ссылки есть название. Лучше делать его видимым, хотя WCAG разрешает добавлять для кнопок визуально скрытые имена. Они доступны только пользователям вспомогательных технологий.
К примеру, когда пользователь скринридера услышит «Найдите круглую синюю кнопку в левом углу экрана», это не поможет ему найти эту кнопку. Скринридеры не рассказывают о цветах и других стилях элементов, а ещё сложно понять на слух, где право и лево на сайте.
Ещё внешний вид и расположение элементов могут отличаться в зависимости от темы на сайте, размера экрана и при разном освещении и яркости.
Чтобы инструкция про кнопку стала понятной всем, можно рассказать чуть больше про неё: «Найдите круглую синюю кнопку с названием «Следующая страница» в левом углу экрана». Теперь пользователь скринридера знает её название и может найти в списке всех кнопок или перейти к ней без списка.
В инструкциях полезно описывать внешние характеристики элемента. Это помогает некоторым пользователям с когнитивными особенностями и нейроотличиями, так что критерий не призывает рассказывать только о названиях и функциях.
Критерий перекликается с одним из принципов универсального дизайна о легко воспринимаемой информации. Этот принцип требует использовать несколько каналов восприятия — визуальный, аудиальный, тактильный и вербальный.
Несколько примеров инструкций, в которых что-то пошло не так:
  • Больше информации найдёте справа.
  • Если кликните на стрелку, перейдёте к следующему шагу.
  • Важная информация выделена жёлтым цветом.
  • Кликните по круглой синей кнопке в верхнем правом углу.
Что касается «выше» и «ниже», всё зависит от контекста и языка. Пользователям может быть понятно, что содержимое находится до определённой точки или после неё.
Кому это важно
  • Пользователям со слепотой и слабовидящим, которые много полагаются на слух.
  • Пользователям с глухотой и слабослышащим, которым важно видеть содержимое.
  • Пользователям мобильных устройств. Расположение элементов на странице в мобильной версии сайта может отличаться от десктопной.
Как избежать барьер
Этот барьер обычно появляется на этапе информационного дизайна и написания текстов, поэтому хорошо заранее обращать внимание понятность и доступность инструкций.
Разработчики могут следить за названиями элементов в коде и давать кнопкам, ссылкам и другим элементам хотя бы визуально скрытые названия. Также хорошо использовать заголовки для разных частей страницы, например, для бокового меню или списков со ссылками.
Примеры соответствия критерию
  • В правой части страницы есть список ссылок на тарифные планы. В тексте сказано: «Выберите тарифный план из списка с заголовком «Наши тарифные планы». Он находится справа».
  • При заполнении поля появилась ошибка. В ней использована иконка с крестиком и текст «Вы неправильно заполнили поле. Рекомендуем формат месяц-дата-число».
На сайте Vimeo есть форма регистрации нового пользователя. Если ввёл неправильные данные в одно из полей, например, для почты, под ним появится текстовая ошибка «Введите правильный адрес электронной почты, пожалуйста». Неправильно заполненное поле при этом тоже визуально изменится. К нему добавится красная рамка и иконка с восклицательным знаком внутри.
Форма «Присоединиться к Vimeo». Выделено поле «Email», в него частично введён адрес «myemail@».
Форма регистрации на Vimeo.
Примеры барьеров
  • На сайте карусель с кнопками со стрелками влево и вправо. В инструкции на странице написано: «Для перехода к следующему товару нажмите на правую кнопку, для возврата — на левую кнопку».
  • На странице есть боковое меню со списком ссылок на другие статьи. В инструкции на странице сказано: «Другие статьи найдёте в боковом меню справа».
  • При заполнении поля появилась ошибка. В ней только иконка с крестиком без видимого или визуально скрытого текста.
  • Страница с тестом. Время для его прохождения ограничено. В инструкции перед тестом написано: «Когда время истечёт, вы услышите сигнал об этом».
  • На странице таблица с разноцветными строками. Под таблицей пояснение: «Зелёные строки в таблице означают прибыль компании в этом месяце, а красные — расходы».
В десктопной версии TikTok раньше была инструкция, как войти в личный аккаунт с помощью QR-кода. В инструкции был скриншот мобильного приложения и описание шагов. Первый — «откройте приложение TikTok на своём мобильном устройстве». Второй — «в профиле тапните…», и тут вместо текста иконка с человечком и крестиком. Последний шаг — «тапните…», и опять вместо строчки текста иконка с пунктирной рамкой и горизонтальной чертой по центру.
Модальное окно с заголовком «Залогиниться с помощью QR-кода».
Инструкция для входа в TikTok-аккаунт с помощью QR-кода.
Как тестировать
С поиском проблем с сенсорными характеристиками поможет только ручное тестирование.
  • Найдите страницы, где есть инструкции.
  • Убедитесь, что в них описан не только внешний вид элементов и их положение на странице.
Что почитать
Другие статьи
 Татьяна Фокина, 2021–2024
Разработано на 11ty, иконки с Lucide Нашли ошибку? Поделитесь ей на GitHub

\ No newline at end of file
diff --git a/ru/articles/wcag-target-size/index.html b/ru/articles/wcag-target-size/index.html
index 817508d..eca4715 100644
--- a/ru/articles/wcag-target-size/index.html
+++ b/ru/articles/wcag-target-size/index.html
@@ -21,7 +21,7 @@
 			},
 			"datePublished": "2022-10-31T00:00:00.000Z",
 			"dateModified": "2024-09-02T00:00:00.000Z"
-		}
 
Размер цели
  • WCAG
  • UX
  • CSS
 
 Обновлено: 
В этом посте из серии про разбор Руководств по доступности веб-контента (Web Content Accessibility Guidelines, коротко WCAG) расскажу про несколько принципов, связанных с размером интерактивных элементов.
Во WCAG 2.1 c этим принципом связан критерий 2.5.5: Размер цели, и он самого высокого уровня AAA.
Во WCAG 2.2 появился ещё один критерий, который устанавливает минимальные требования к размеру элементов. Это критерий 2.5.8: Размер цели (Минимальный), он относится к уровню AA.
Оба критерия относятся к руководству по воспринимаемости и его подразделу о способах ввода.
Коротко о критериях
Величина целей должна быть определённых размеров в пикселях.
Это требование касается интерактивных элементов, с которыми взаимодействуют пользователи с помощью разных указателей — мышки, стилуса, пера, головного указателя или пальца.
Подробнее
В основном принцип касается размеров кнопок, отдельных ссылок на странице, полей и похожих элементов. При этом есть элементы, размеры которых не надо учитывать:
  • Элементы с браузерными стилями, которые не изменяли.
  • Элементы, размер и расстояние между которыми нельзя изменить, так как это связано с их смыслом или с требованиями законов. Например, маркеры на карте.
  • Ссылки в тексте.
  • Два одинаковых по функциональности элемента на странице, один из которых нужного размера.
Критерий про размер целей касается любых интерфейсов, но особенно мобильных. Интерактивный элемент, на который легко кликать мышкой, может быть слишком маленьким для пользователя мобильного устройства. Это называется асимметрия видимости и нажатия (view–tap asymmetry).
Также есть закон, который описывает важность размера цели, — закон Фиттса. Он гласит, что время, которое нужно для достижения цели, зависит от размеров этой цели и расстояния до неё. В интерфейсах чем меньше интерактивный элемент, тем сложнее до него добраться. С большим элементом легче взаимодействовать, а ещё проще найти на странице.
Чтобы пользователи не сталкивались с этой проблемой, максимальный размер интерактивного элемента должен быть 44 на 44 пикселя и выше. Так как это не так просто сделать на практике, принцип в первую очередь касается следующих случаев:
  • Элементы, которыми часто пользуются. Например, ссылка с иконкой корзины для перехода к оплате покупок в интернет-магазине.
  • Элемент, который помогает изменять результат работы другого элемента. Пример — кнопка редактирования формы после её отправки.
  • Элемент, до которого сложно дотянуться. К примеру кнопка в верхнем правом углу экрана.
  • Элемент из группы других, которые являются частью одного действия. Например, кнопка с переходом к следующему шагу в форме.
Минимальный размер интерактивного элемента — 24 на 24 пикселя.
Ещё важно расстояние между элементами. Если расположить их слишком близко друг к другу, это спровоцирует ошибку касания цели (touch-target error). Пользователи будут чаще промахиваться и нажимать не на тот элемент. Так что, если размер несколько кнопок 20px, а расстояние между ними 4px, это соответствует минимальным требованиям к размерам целей. В общей сумме их размер и расстояние между ними — 24px.
Следить за расстоянием между элементами стоит не только в случае кнопок, но и у списков ссылок. Например, в обычном блоке со ссылками на странице, в выпадающем списке меню или у комбинированного списка.
Посмотрим на что-то более наглядное. На картинке показаны достаточно большие кнопки и ссылки, которые проходят критерий. Кнопка «Настройки» шириной 115 пикселей и высотой 44 пикселя, а кнопка с иконкой лупы — 44 на 44. Другая кнопка с иконкой со стрелкой вниз минимального размера 24 на 24 пикселя. Группа из двух кнопок, размер которых 44 на 44 пикселя, находятся друг от друга на расстоянии в 22 пикселя. Ну и что касается списков, то размеры ссылок «Гёзда», «Хинкали», «Равиоли» — 20 пикселей, а высота строки — 27. Высота ссылок в другом, выпадающем списке — 24 пикселя.
Хорошие примеры
Элементы, которые соответствуют критериям о размере целей.
Теперь посмотрим на картинку с плохими, небольшими элементами. Кнопка с иконкой со стрелкой вниз всего 23 пикселя в ширину и 23 пикселя в высоту. В группе кнопок, размером 22 на 22 пикселя, между ними нет пустого пространства. Размеры пунктов ссылок в списке — 20 пикселей, а вот высота строки всего 21. Наконец, в выпадающем списке высота ссылок — 21 пиксель.
Плохие примеры
Элементы, которые нарушают оба критерия.
Почему такие размеры целей
За рекомендуемыми размерами интерактивных элементов стоит несколько исследований.
MIT Touch Lab в 2005 проводила исследование про размер пальцев рук людей (PDF). Результаты показали, что средний размер указательных пальцев взрослых людей 1.6–2 сантиметра, а большого пальца — 2.5 сантиметра. Если переводить это в пиксели, получится 45–57 пикселей и 72 пикселя соответственно.
В 2006 Пекка Фархи, Эми Карлсон и Бенджамин Бедерсон установили оптимальный размер целей на сенсорном экране, если взаимодействовать с ним одной рукой. Это минимум 1 на 1 сантиметр. Если переводить сантиметры в пиксели, получится 28 на 28 пикселей. Также они выяснили, что чем больше размер интерактивного элемента на экране, тем меньше ошибок совершают пользователи. Это же показало другое исследование дизайна сенсорных клавиш для выбора цели на мобильном телефоне (PDF).
Кому это важно
  • Пользователи с особенностями устройства скелета и мышц — с церебральным параличом, мышечной дистрофией, артритом.
  • Пользователи с особенностями мелкой моторики — с тремором из-за рассеянного склероза, болезни Паркинсона, инсультом, диспраксией и другими состояниями.
  • Пользователи с пониженным, сниженным зрением или слабовидящие.
  • Пользователи с крупными пальцами.
  • Все пользователи мобильных устройств, особенно когда они пользуются ими в транспорте или на ходу.
Как избежать барьер
Критерии в основном связаны с дизайном, так что в первую очередь важно всё продумать на этом этапе.
В коде проблему с небольшими кнопками можно исправить, если увеличить область клика. Есть несколько способов: с помощью padding или min-width и min-height.
button {
+		}
 
Размер цели
  • WCAG
  • UX
  • CSS
 
 Обновлено: 
В этом посте из серии про разбор Руководств по доступности веб-контента (Web Content Accessibility Guidelines, коротко WCAG) расскажу про несколько принципов, связанных с размером интерактивных элементов.
Во WCAG 2.1 c этим принципом связан критерий 2.5.5: Размер цели, и он самого высокого уровня AAA.
Во WCAG 2.2 появился ещё один критерий, который устанавливает минимальные требования к размеру элементов. Это критерий 2.5.8: Размер цели (Минимальный), он относится к уровню AA.
Оба критерия относятся к руководству по воспринимаемости и его подразделу о способах ввода.
Коротко о критериях
Величина целей должна быть определённых размеров в пикселях.
Это требование касается интерактивных элементов, с которыми взаимодействуют пользователи с помощью разных указателей — мышки, стилуса, пера, головного указателя или пальца.
Подробнее
В основном принцип касается размеров кнопок, отдельных ссылок на странице, полей и похожих элементов. При этом есть элементы, размеры которых не надо учитывать:
  • Элементы с браузерными стилями, которые не изменяли.
  • Элементы, размер и расстояние между которыми нельзя изменить, так как это связано с их смыслом или с требованиями законов. Например, маркеры на карте.
  • Ссылки в тексте.
  • Два одинаковых по функциональности элемента на странице, один из которых нужного размера.
Критерий про размер целей касается любых интерфейсов, но особенно мобильных. Интерактивный элемент, на который легко кликать мышкой, может быть слишком маленьким для пользователя мобильного устройства. Это называется асимметрия видимости и нажатия (view–tap asymmetry).
Также есть закон, который описывает важность размера цели, — закон Фиттса. Он гласит, что время, которое нужно для достижения цели, зависит от размеров этой цели и расстояния до неё. В интерфейсах чем меньше интерактивный элемент, тем сложнее до него добраться. С большим элементом легче взаимодействовать, а ещё проще найти на странице.
Чтобы пользователи не сталкивались с этой проблемой, максимальный размер интерактивного элемента должен быть 44 на 44 пикселя и выше. Так как это не так просто сделать на практике, принцип в первую очередь касается следующих случаев:
  • Элементы, которыми часто пользуются. Например, ссылка с иконкой корзины для перехода к оплате покупок в интернет-магазине.
  • Элемент, который помогает изменять результат работы другого элемента. Пример — кнопка редактирования формы после её отправки.
  • Элемент, до которого сложно дотянуться. К примеру кнопка в верхнем правом углу экрана.
  • Элемент из группы других, которые являются частью одного действия. Например, кнопка с переходом к следующему шагу в форме.
Минимальный размер интерактивного элемента — 24 на 24 пикселя.
Ещё важно расстояние между элементами. Если расположить их слишком близко друг к другу, это спровоцирует ошибку касания цели (touch-target error). Пользователи будут чаще промахиваться и нажимать не на тот элемент. Так что, если размер несколько кнопок 20px, а расстояние между ними 4px, это соответствует минимальным требованиям к размерам целей. В общей сумме их размер и расстояние между ними — 24px.
Следить за расстоянием между элементами стоит не только в случае кнопок, но и у списков ссылок. Например, в обычном блоке со ссылками на странице, в выпадающем списке меню или у комбинированного списка.
Посмотрим на что-то более наглядное. На картинке показаны достаточно большие кнопки и ссылки, которые проходят критерий. Кнопка «Настройки» шириной 115 пикселей и высотой 44 пикселя, а кнопка с иконкой лупы — 44 на 44. Другая кнопка с иконкой со стрелкой вниз минимального размера 24 на 24 пикселя. Группа из двух кнопок, размер которых 44 на 44 пикселя, находятся друг от друга на расстоянии в 22 пикселя. Ну и что касается списков, то размеры ссылок «Гёзда», «Хинкали», «Равиоли» — 20 пикселей, а высота строки — 27. Высота ссылок в другом, выпадающем списке — 24 пикселя.
Хорошие примеры
Элементы, которые соответствуют критериям о размере целей.
Теперь посмотрим на картинку с плохими, небольшими элементами. Кнопка с иконкой со стрелкой вниз всего 23 пикселя в ширину и 23 пикселя в высоту. В группе кнопок, размером 22 на 22 пикселя, между ними нет пустого пространства. Размеры пунктов ссылок в списке — 20 пикселей, а вот высота строки всего 21. Наконец, в выпадающем списке высота ссылок — 21 пиксель.
Плохие примеры
Элементы, которые нарушают оба критерия.
Почему такие размеры целей
За рекомендуемыми размерами интерактивных элементов стоит несколько исследований.
MIT Touch Lab в 2005 проводила исследование про размер пальцев рук людей (PDF). Результаты показали, что средний размер указательных пальцев взрослых людей 1.6–2 сантиметра, а большого пальца — 2.5 сантиметра. Если переводить это в пиксели, получится 45–57 пикселей и 72 пикселя соответственно.
В 2006 Пекка Фархи, Эми Карлсон и Бенджамин Бедерсон установили оптимальный размер целей на сенсорном экране, если взаимодействовать с ним одной рукой. Это минимум 1 на 1 сантиметр. Если переводить сантиметры в пиксели, получится 28 на 28 пикселей. Также они выяснили, что чем больше размер интерактивного элемента на экране, тем меньше ошибок совершают пользователи. Это же показало другое исследование дизайна сенсорных клавиш для выбора цели на мобильном телефоне (PDF).
Кому это важно
  • Пользователи с особенностями устройства скелета и мышц — с церебральным параличом, мышечной дистрофией, артритом.
  • Пользователи с особенностями мелкой моторики — с тремором из-за рассеянного склероза, болезни Паркинсона, инсультом, диспраксией и другими состояниями.
  • Пользователи с пониженным, сниженным зрением или слабовидящие.
  • Пользователи с крупными пальцами.
  • Все пользователи мобильных устройств, особенно когда они пользуются ими в транспорте или на ходу.
Как избежать барьер
Критерии в основном связаны с дизайном, так что в первую очередь важно всё продумать на этом этапе.
В коде проблему с небольшими кнопками можно исправить, если увеличить область клика. Есть несколько способов: с помощью padding или min-width и min-height.
button {
   font-size: 14px;
   padding: 20px;
 }
ul li {
diff --git a/ru/feed.xml b/ru/feed.xml
index 0afafe9..b63b51f 100644
--- a/ru/feed.xml
+++ b/ru/feed.xml
@@ -1 +1 @@
-Блог о цифровой доступностиПрактические советы по цифровой доступности для фронтенд-разработчиков, QA тестировщиков и дизайнеров. Тут вы узнаете о методах создания доступных и удобных интерфейсов, стандартах, ассистивных технологиях и законах.https://a11y-blog.dev/Tue, 07 Mar 2023 00:00:00 GMTКлавиатураРазбираемся с критерием про доступность интерфейса для клавиатуры.https://a11y-blog.dev/ru/articles/wcag-keyboard/Tue, 07 Mar 2023 00:00:00 GMThttps://a11y-blog.dev/ru/articles/wcag-keyboard/Внешний вид фокусаКак должны выглядеть элементы при фокусе с клавиатуры по мнению WCAG 2.2.https://a11y-blog.dev/ru/articles/wcag-focus-appearance/Fri, 27 Jan 2023 00:00:00 GMThttps://a11y-blog.dev/ru/articles/wcag-focus-appearance/Информация и взаимосвязиПочему важно подкреплять визуальное представление элементов правильной разметкой.https://a11y-blog.dev/ru/articles/wcag-info-and-relationships/Tue, 17 Jan 2023 00:00:00 GMThttps://a11y-blog.dev/ru/articles/wcag-info-and-relationships/Название страницыПочему у страниц должны быть названия и как их правильно составлять.https://a11y-blog.dev/ru/articles/wcag-page-titled/Fri, 30 Dec 2022 00:00:00 GMThttps://a11y-blog.dev/ru/articles/wcag-page-titled/Видимый фокусРазбираемся с критерием о видимом клавиатурном фокусе у интерактивных элементов.https://a11y-blog.dev/ru/articles/wcag-focus-visible/Sun, 18 Dec 2022 00:00:00 GMThttps://a11y-blog.dev/ru/articles/wcag-focus-visible/Нетекстовое содержимоеЧто такое нетекстовое содержимое и текстовые альтернативы.https://a11y-blog.dev/ru/articles/wcag-non-text-content/Mon, 28 Nov 2022 00:00:00 GMThttps://a11y-blog.dev/ru/articles/wcag-non-text-content/Клавиша символа в клавиатурном сокращенииПочему клавиатурные сокращения с одним печатным символом, буквой или цифрой — барьер для пользователей.https://a11y-blog.dev/ru/articles/wcag-character-key/Mon, 14 Nov 2022 00:00:00 GMThttps://a11y-blog.dev/ru/articles/wcag-character-key/Сенсорные характеристикиЧто такое сенсорные характеристики в инструкциях и как не создать этот барьер.https://a11y-blog.dev/ru/articles/wcag-sensory-characteristics/Mon, 07 Nov 2022 00:00:00 GMThttps://a11y-blog.dev/ru/articles/wcag-sensory-characteristics/Размер целиЧто такое размер цели, и как не создать такой барьер для пользователей вашего сайта.https://a11y-blog.dev/ru/articles/wcag-target-size/Mon, 31 Oct 2022 00:00:00 GMThttps://a11y-blog.dev/ru/articles/wcag-target-size/Консистентная идентификацияЧто такое консистентная идентификация на страницах и как не запутать пользователей инструкциями.https://a11y-blog.dev/ru/articles/wcag-consistent-identification/Sat, 22 Oct 2022 00:00:00 GMThttps://a11y-blog.dev/ru/articles/wcag-consistent-identification/role с несколькими значениямиРазберёмся с несколькими значениями у атрибута для роли. В каких случаях это пригодится, и какие отношения с двумя ролями у браузеров и скринридеров.https://a11y-blog.dev/ru/articles/aria-attribute-role-with-multiple-values/Mon, 24 Jan 2022 00:00:00 GMThttps://a11y-blog.dev/ru/articles/aria-attribute-role-with-multiple-values/CSS-медиафичи для улучшения доступностиКакие пользовательские настройки бывают и как их учитывать в веб-интерфейсах. Узнаете про медиафичи, которые отслеживают настройки анимации, контрастности, прозрачности, инверсию, цветовую схему и режим принудительных цветов.https://a11y-blog.dev/ru/articles/css-media-features-for-a11y/Mon, 01 Nov 2021 00:00:00 GMThttps://a11y-blog.dev/ru/articles/css-media-features-for-a11y/Разбираемся со skip linkКак пропустить большую навигацию с помощью skip link, кому нужны такие ссылки и как их добавить на свой сайт.https://a11y-blog.dev/ru/articles/understanding-a-skip-link/Mon, 23 Aug 2021 00:00:00 GMThttps://a11y-blog.dev/ru/articles/understanding-a-skip-link/Как не навредить пользователям с эпилепсией и вестибулярными нарушениямиЧто, если пользователя укачивает из-за сайта? А вдруг у него случится эпилептический приступ? Давайте разберёмся с тем, какими должны быть интерфейсы для пользователей с эпилепсией и вестибулярными нарушениями.https://a11y-blog.dev/ru/articles/how-to-protect-users-with-epilepsy-and-vd/Mon, 19 Jul 2021 00:00:00 GMThttps://a11y-blog.dev/ru/articles/how-to-protect-users-with-epilepsy-and-vd/
\ No newline at end of file
+Блог о цифровой доступностиПрактические советы по цифровой доступности для фронтенд-разработчиков, QA тестировщиков и дизайнеров. Тут вы узнаете о методах создания доступных и удобных интерфейсов, стандартах, ассистивных технологиях и законах.https://a11y-blog.dev/Tue, 07 Mar 2023 00:00:00 GMTКлавиатураРазбираемся с критерием про доступность интерфейса для клавиатуры.https://a11y-blog.dev/ru/articles/wcag-keyboard/Tue, 07 Mar 2023 00:00:00 GMThttps://a11y-blog.dev/ru/articles/wcag-keyboard/Внешний вид фокусаКак должны выглядеть элементы при фокусе с клавиатуры по мнению WCAG 2.2.https://a11y-blog.dev/ru/articles/wcag-focus-appearance/Fri, 27 Jan 2023 00:00:00 GMThttps://a11y-blog.dev/ru/articles/wcag-focus-appearance/Информация и взаимосвязиПочему важно подкреплять визуальное представление элементов правильной разметкой.https://a11y-blog.dev/ru/articles/wcag-info-and-relationships/Tue, 17 Jan 2023 00:00:00 GMThttps://a11y-blog.dev/ru/articles/wcag-info-and-relationships/Название страницыПочему у страниц должны быть названия и как их правильно составлять.https://a11y-blog.dev/ru/articles/wcag-page-titled/Fri, 30 Dec 2022 00:00:00 GMThttps://a11y-blog.dev/ru/articles/wcag-page-titled/Видимый фокусРазбираемся с критерием о видимом клавиатурном фокусе у интерактивных элементов.https://a11y-blog.dev/ru/articles/wcag-focus-visible/Sun, 18 Dec 2022 00:00:00 GMThttps://a11y-blog.dev/ru/articles/wcag-focus-visible/Нетекстовое содержимоеЧто такое нетекстовое содержимое и текстовые альтернативы.https://a11y-blog.dev/ru/articles/wcag-non-text-content/Mon, 28 Nov 2022 00:00:00 GMThttps://a11y-blog.dev/ru/articles/wcag-non-text-content/Клавиша символа в клавиатурном сокращенииПочему клавиатурные сокращения с одним печатным символом, буквой или цифрой — барьер для пользователей.https://a11y-blog.dev/ru/articles/wcag-character-key/Mon, 14 Nov 2022 00:00:00 GMThttps://a11y-blog.dev/ru/articles/wcag-character-key/Сенсорные характеристикиЧто такое сенсорные характеристики в инструкциях и как не создать этот барьер.https://a11y-blog.dev/ru/articles/wcag-sensory-characteristics/Mon, 07 Nov 2022 00:00:00 GMThttps://a11y-blog.dev/ru/articles/wcag-sensory-characteristics/Размер целиЧто такое размер цели, и как не создать такой барьер для пользователей вашего сайта.https://a11y-blog.dev/ru/articles/wcag-target-size/Mon, 31 Oct 2022 00:00:00 GMThttps://a11y-blog.dev/ru/articles/wcag-target-size/Консистентная идентификацияЧто такое консистентная идентификация на страницах и как не запутать пользователей инструкциями.https://a11y-blog.dev/ru/articles/wcag-consistent-identification/Sat, 22 Oct 2022 00:00:00 GMThttps://a11y-blog.dev/ru/articles/wcag-consistent-identification/role с несколькими значениямиРазберёмся с несколькими значениями у атрибута для роли. В каких случаях это пригодится, и какие отношения с двумя ролями у браузеров и скринридеров.https://a11y-blog.dev/ru/articles/aria-attribute-role-with-multiple-values/Mon, 24 Jan 2022 00:00:00 GMThttps://a11y-blog.dev/ru/articles/aria-attribute-role-with-multiple-values/CSS-медиафичи для улучшения доступностиКакие пользовательские настройки бывают и как их учитывать в веб-интерфейсах. Узнаете про медиафичи, которые отслеживают настройки анимации, контрастности, прозрачности, инверсию, цветовую схему и режим принудительных цветов.https://a11y-blog.dev/ru/articles/css-media-features-for-a11y/Mon, 01 Nov 2021 00:00:00 GMThttps://a11y-blog.dev/ru/articles/css-media-features-for-a11y/Разбираемся со skip linkКак пропустить большую навигацию с помощью skip link, кому нужны такие ссылки и как их добавить на свой сайт.https://a11y-blog.dev/ru/articles/understanding-a-skip-link/Mon, 23 Aug 2021 00:00:00 GMThttps://a11y-blog.dev/ru/articles/understanding-a-skip-link/Как не навредить пользователям с эпилепсией и вестибулярными нарушениямиЧто, если пользователя укачивает из-за сайта? А вдруг у него случится эпилептический приступ? Давайте разберёмся с тем, какими должны быть интерфейсы для пользователей с эпилепсией и вестибулярными нарушениями.https://a11y-blog.dev/ru/articles/how-to-protect-users-with-epilepsy-and-vd/Mon, 19 Jul 2021 00:00:00 GMThttps://a11y-blog.dev/ru/articles/how-to-protect-users-with-epilepsy-and-vd/
diff --git a/ru/index.html b/ru/index.html
index 5ee2441..681ae4e 100644
--- a/ru/index.html
+++ b/ru/index.html
@@ -1 +1 @@
-Блог о цифровой доступности
 
Статьи про цифровую доступность
Привет, я Татьяна Фокина, но вы можете звать меня просто Таня. Я специалистка по веб-доступности, которая любит создавать дружелюбные интерфейсы и обсуждать цифровую доступность с другими (иногда посреди ночи).
В этом блоге делюсь практическими советами, хаками, полезными ссылками, своими мыслями и просто интересными находками о доступной разработке и инклюзии ✨
Если хотите спросить меня о моих статьях или доступности, ищите меня на LinkedIn или в Твиттере.
Недавние статьи
Клавиатура
Разбираемся с критерием про доступность интерфейса для клавиатуры.
  • WCAG
  • Клавиатура
  • HTML
 
Внешний вид фокуса
Как должны выглядеть элементы при фокусе с клавиатуры по мнению WCAG 2.2.
  • WCAG
  • Дизайн
  • CSS
  • Клавиатура
 
Информация и взаимосвязи
Почему важно подкреплять визуальное представление элементов правильной разметкой.
  • WCAG
  • HTML
  • CSS
  • ARIA
 
Все статьи
 Татьяна Фокина, 2021–2024
Разработано на 11ty, иконки с Lucide Нашли ошибку? Поделитесь ей на GitHub

\ No newline at end of file
+Блог о цифровой доступности
 
Статьи про цифровую доступность
Привет, я Татьяна Фокина, но вы можете звать меня просто Таня. Я специалистка по веб-доступности, которая любит создавать дружелюбные интерфейсы и обсуждать цифровую доступность с другими (иногда посреди ночи).
В этом блоге делюсь практическими советами, хаками, полезными ссылками, своими мыслями и просто интересными находками о доступной разработке и инклюзии ✨
Если хотите спросить меня о моих статьях или доступности, ищите меня на LinkedIn или в Твиттере.
Недавние статьи
Клавиатура
Разбираемся с критерием про доступность интерфейса для клавиатуры.
  • WCAG
  • Клавиатура
  • HTML
 
Внешний вид фокуса
Как должны выглядеть элементы при фокусе с клавиатуры по мнению WCAG 2.2.
  • WCAG
  • Дизайн
  • CSS
  • Клавиатура
 
Информация и взаимосвязи
Почему важно подкреплять визуальное представление элементов правильной разметкой.
  • WCAG
  • HTML
  • CSS
  • ARIA
 
Все статьи
 Татьяна Фокина, 2021–2024
Разработано на 11ty, иконки с Lucide Нашли ошибку? Поделитесь ей на GitHub

\ No newline at end of file
diff --git a/scripts/color-theme/color-theme.js b/scripts/color-theme/color-theme.js
index 4365417..32691b1 100644
--- a/scripts/color-theme/color-theme.js
+++ b/scripts/color-theme/color-theme.js
@@ -72,4 +72,4 @@ export function colorTheme() {
 			theme.value = isDark ? "dark" : "light";
 			setPreference();
 		});
-}
\ No newline at end of file
+}
diff --git a/scripts/scripts.js b/scripts/scripts.js
index 4cee877..181550f 100644
--- a/scripts/scripts.js
+++ b/scripts/scripts.js
@@ -1,3 +1,3 @@
-import { colorTheme } from './color-theme/color-theme.js';
+import { colorTheme } from "./color-theme/color-theme.js";
 
-colorTheme();
\ No newline at end of file
+colorTheme();
diff --git a/sitemap.xml b/sitemap.xml
index b871bad..9cec496 100644
--- a/sitemap.xml
+++ b/sitemap.xml
@@ -1 +1 @@
-https://a11y-blog.dev/ru/articles/how-to-protect-users-with-epilepsy-and-vd/2021-07-19T00:00:00.000Zmonthlyhttps://a11y-blog.dev/ru/articles/understanding-a-skip-link/2021-08-23T00:00:00.000Zmonthlyhttps://a11y-blog.dev/ru/articles/css-media-features-for-a11y/2021-11-01T00:00:00.000Zmonthlyhttps://a11y-blog.dev/ru/articles/aria-attribute-role-with-multiple-values/2022-01-24T00:00:00.000Zmonthlyhttps://a11y-blog.dev/ru/articles/wcag-consistent-identification/2022-10-22T00:00:00.000Zmonthlyhttps://a11y-blog.dev/ru/articles/wcag-target-size/2022-10-31T00:00:00.000Zmonthlyhttps://a11y-blog.dev/ru/articles/wcag-sensory-characteristics/2022-11-07T00:00:00.000Zmonthlyhttps://a11y-blog.dev/ru/articles/wcag-character-key/2022-11-14T00:00:00.000Zmonthlyhttps://a11y-blog.dev/ru/articles/wcag-non-text-content/2022-11-28T00:00:00.000Zmonthlyhttps://a11y-blog.dev/ru/articles/wcag-focus-visible/2022-12-18T00:00:00.000Zmonthlyhttps://a11y-blog.dev/ru/articles/wcag-page-titled/2022-12-30T00:00:00.000Zmonthlyhttps://a11y-blog.dev/ru/articles/wcag-info-and-relationships/2023-01-17T00:00:00.000Zmonthlyhttps://a11y-blog.dev/ru/articles/wcag-focus-appearance/2023-01-27T00:00:00.000Zmonthlyhttps://a11y-blog.dev/ru/articles/wcag-keyboard/2023-03-07T00:00:00.000Zmonthlyhttps://a11y-blog.dev/en/articles/understanding-a-skip-link/2024-05-05T00:00:00.000Zmonthlyhttps://a11y-blog.dev/en/articles/css-media-features-for-a11y/2024-05-09T00:00:00.000Zmonthlyhttps://a11y-blog.dev/en/articles/aria-live-regions/2024-05-11T00:00:00.000Zmonthlyhttps://a11y-blog.dev/en/articles/how-to-protect-users-with-epilepsy-and-vd/2024-05-16T00:00:00.000Zmonthlyhttps://a11y-blog.dev/en/articles/aria-attribute-role-with-multiple-values/2024-06-03T00:00:00.000Zmonthlyhttps://a11y-blog.dev/en/articles/2024-06-03T15:25:06.280Zmonthlyhttps://a11y-blog.dev/en/2024-06-03T15:25:06.281Zmonthlyhttps://a11y-blog.dev/ru/articles/2024-06-03T15:25:06.299Zmonthlyhttps://a11y-blog.dev/ru/2024-06-03T15:25:06.354Zmonthly
\ No newline at end of file
+https://a11y-blog.dev/ru/articles/how-to-protect-users-with-epilepsy-and-vd/2021-07-19T00:00:00.000Zmonthlyhttps://a11y-blog.dev/ru/articles/understanding-a-skip-link/2021-08-23T00:00:00.000Zmonthlyhttps://a11y-blog.dev/ru/articles/css-media-features-for-a11y/2021-11-01T00:00:00.000Zmonthlyhttps://a11y-blog.dev/ru/articles/aria-attribute-role-with-multiple-values/2022-01-24T00:00:00.000Zmonthlyhttps://a11y-blog.dev/ru/articles/wcag-consistent-identification/2022-10-22T00:00:00.000Zmonthlyhttps://a11y-blog.dev/ru/articles/wcag-target-size/2022-10-31T00:00:00.000Zmonthlyhttps://a11y-blog.dev/ru/articles/wcag-sensory-characteristics/2022-11-07T00:00:00.000Zmonthlyhttps://a11y-blog.dev/ru/articles/wcag-character-key/2022-11-14T00:00:00.000Zmonthlyhttps://a11y-blog.dev/ru/articles/wcag-non-text-content/2022-11-28T00:00:00.000Zmonthlyhttps://a11y-blog.dev/ru/articles/wcag-focus-visible/2022-12-18T00:00:00.000Zmonthlyhttps://a11y-blog.dev/ru/articles/wcag-page-titled/2022-12-30T00:00:00.000Zmonthlyhttps://a11y-blog.dev/ru/articles/wcag-info-and-relationships/2023-01-17T00:00:00.000Zmonthlyhttps://a11y-blog.dev/ru/articles/wcag-focus-appearance/2023-01-27T00:00:00.000Zmonthlyhttps://a11y-blog.dev/ru/articles/wcag-keyboard/2023-03-07T00:00:00.000Zmonthlyhttps://a11y-blog.dev/en/articles/understanding-a-skip-link/2024-05-05T00:00:00.000Zmonthlyhttps://a11y-blog.dev/en/articles/css-media-features-for-a11y/2024-05-09T00:00:00.000Zmonthlyhttps://a11y-blog.dev/en/articles/aria-live-regions/2024-05-11T00:00:00.000Zmonthlyhttps://a11y-blog.dev/en/articles/how-to-protect-users-with-epilepsy-and-vd/2024-05-16T00:00:00.000Zmonthlyhttps://a11y-blog.dev/en/articles/aria-attribute-role-with-multiple-values/2024-06-03T00:00:00.000Zmonthlyhttps://a11y-blog.dev/en/articles/2024-06-03T15:25:06.280Zmonthlyhttps://a11y-blog.dev/en/2024-06-03T15:25:06.281Zmonthlyhttps://a11y-blog.dev/ru/articles/2024-06-03T15:25:06.299Zmonthlyhttps://a11y-blog.dev/ru/2024-06-03T15:25:06.354Zmonthly
diff --git a/styles/styles.css b/styles/styles.css
index 507f71b..48557f5 100644
--- a/styles/styles.css
+++ b/styles/styles.css
@@ -1 +1 @@
-@media (prefers-reduced-motion:no-preference){a,.header__switcher-button{transition:background .2s}.navigation__list-item-link{transition:color .2s}.cards__item{transition:background .3s}}.base[data-theme=light]{--select-color:#c7759e3a;--bg-color:#c8d5d6;--bg-part-color:#dae3e4;--text-color:#2f445d;--code-color:#b6c7dc;--border-color:#566c87;--color-hover:#b7caca;--menu-elements-color-hover:#65778e;--button-bg-color:#2f445d;--button-text-color:#c8d5d6;--img-filter:unset}.base[data-theme=dark]{--select-color:fuchsia-alpha;--bg-color:#14202f;--bg-part-color:#2f445d;--text-color:#b7caca;--code-color:#2f445d;--border-color:#c8d5d6;--color-hover:#1b2c41;--menu-elements-color-hover:#859ab4;--button-bg-color:#c8d5d6;--button-text-color:#435872;--img-filter:brightness(.8)contrast(1.2)}*,:before,:after{box-sizing:border-box;margin:0}.base{color:var(--text-color);background:var(--bg-color);flex-direction:column;min-height:100vh;margin:0;display:flex}.wrapper{width:100%;max-width:780px;margin:0 auto;padding:0 20px}.base__body{flex:1 0 auto;margin-top:clamp(3.25rem,1.25rem + 4.2254vw - 25.3524px,3.75rem)}@font-face{font-family:IBM Plex Sans;font-style:normal;font-weight:400;font-display:swap;src:url(/fonts/ibm-plex-sans-v8-latin_cyrillic-regular.woff2)format("woff2"),url(/fonts/ibm-plex-sans-v8-latin_cyrillic-regular.woff)format("woff")}@font-face{font-family:IBM Plex Sans;font-style:normal;font-weight:700;font-display:swap;src:url(/fonts/ibm-plex-sans-v8-latin_cyrillic-700.woff2)format("woff2"),url(/fonts/ibm-plex-sans-v8-latin_cyrillic-700.woff)format("woff")}@font-face{font-family:IBM Plex Mono;font-style:normal;font-weight:400;font-display:swap;src:url(/fonts/ibm-plex-mono-v6-latin_cyrillic-regular.woff2)format("woff2"),url(/fonts/ibm-plex-mono-v6-latin_cyrillic-regular.woff)format("woff")}h1{font-size:clamp(2.375rem,1.25rem + 4.2254vw - 25.3524px,2.75rem);line-height:1.318}h2{font-size:clamp(1.75rem,1.25rem + 4.2254vw - 25.3524px,2.125rem);line-height:1.263}h3{font-size:clamp(1.5rem,1.25rem + 4.2254vw - 25.3524px,1.75rem);line-height:1.285}h4{line-height:1.5}samp{font-family:IBM Plex Sans,Arial,Helvetica,sans-serif}small,.cards__item-date,.article-header__dates-item,.article__note-text,.article__image-caption{font-size:clamp(.875rem,1.25rem + 4.2254vw - 25.3524px,1rem)}small,.cards__item-date,.article__note-text,.article__image-caption{line-height:1.5}pre,code,kbd{font-family:IBM Plex Mono,Courier New,monospace;font-size:clamp(1rem,1.25rem + 4.2254vw - 25.3524px,1rem)}.topics__item{font-size:clamp(.875rem,1.25rem + 4.2254vw - 25.3524px,.875rem)}.base{font-family:IBM Plex Sans,Arial,Helvetica,sans-serif;font-size:clamp(1.125rem,1.25rem + 4.2254vw - 25.3524px,1.25rem);line-height:1.6}.visually-hidden{clip:rect(1px,1px,1px,1px);width:1px;height:1px;padding:0;list-style:none;position:absolute;left:0;overflow:hidden}.invisible-anchor{position:relative;top:0}@media (width>=768px){.invisible-anchor{top:-40px}}::selection{background:var(--select-color)}p{margin:clamp(.25rem,1.25rem + 4.2254vw - 25.3524px,.5rem) 0}hr{border:0;width:100%;height:15px;margin:clamp(3rem,1.25rem + 4.2254vw - 25.3524px,3.5rem) auto clamp(1.25rem,1.25rem + 4.2254vw - 25.3524px,1.75rem);display:inline-block;position:relative}hr:after{content:"";background-image:url(../assets/wave.svg);background-position:50%;background-repeat:no-repeat;width:100%;height:15px;display:block;position:absolute;top:0;left:0}ul,ol{margin:0}ul:has(a) li{padding:3px 0}code{word-wrap:break-word;color:var(--text-color);background:var(--code-color);border-radius:4px;padding:4px}a>code{padding-bottom:1px}figure{margin:0;padding:0;display:block}blockquote{border-left:4px solid var(--border-color);word-wrap:break-word;margin:20px 0}blockquote p{padding-left:24px}h1{margin:0 0 clamp(.875rem,1.25rem + 4.2254vw - 25.3524px,1.5rem)}h2{margin:clamp(2.25rem,1.25rem + 4.2254vw - 25.3524px,2.75rem) 0 clamp(.9375rem,1.25rem + 4.2254vw - 25.3524px,1rem)}h3{margin:clamp(2rem,1.25rem + 4.2254vw - 25.3524px,1.75rem) 0 clamp(.875rem,1.25rem + 4.2254vw - 25.3524px,.9375rem)}h4{margin:clamp(1.5rem,1.25rem + 4.2254vw - 25.3524px,1.75rem) 0 clamp(.75rem,1.25rem + 4.2254vw - 25.3524px,.875rem)}a{color:var(--text-color);border-bottom:2px solid var(--border-color);text-decoration:none}a:hover{background:var(--color-hover)}a:focus-visible{outline-offset:2px;outline-width:3px;outline-style:dotted;outline-color:var(--border-color);border-bottom:0}img{max-width:100%;height:auto;display:block}@media (forced-colors:active){::selection{background:highlight}a:hover{color:canvas;background:canvastext}.cards__item{border:2px solid #0000}.cards__item:focus-within{outline-offset:2px;outline:4px dotted #0000}.logo__svg-path{fill:none}}@media (inverted-colors){.wrapper img,.wrapper video{filter:invert()}}.article-header{text-align:center;flex-direction:column;gap:24px;display:flex}.article-header__dates{display:inherit;justify-content:center;gap:24px}.article-header__dates-item{display:inherit;align-items:center;gap:4px}.article-header__dates-item__ico{stroke:currentColor;width:1rem;height:auto}.article{margin-top:clamp(3.25rem,1.25rem + 4.2254vw - 25.3524px,3.75rem)}.article__note{background:var(--bg-part-color);border-radius:8px;align-items:flex-start;gap:16px;margin:clamp(.25rem,1.25rem + 4.2254vw - 25.3524px,2rem) 0;padding:clamp(.5rem,1.25rem + 4.2254vw - 25.3524px,1rem);display:flex}.article__note-text{word-break:break-word;margin:0}.article__note-icon{stroke:currentColor;flex-shrink:0;width:2rem;height:auto;display:inline-flex}.article__code{word-wrap:break-word;background:var(--code-color);border-radius:8px;margin:20px 0;padding:clamp(1rem,1.25rem + 4.2254vw - 25.3524px,1.75rem);display:block;overflow-x:auto}.article__image{filter:var(--img-filter);background:#b3a8db;border-radius:16px;flex-direction:column;gap:20px;width:100%;margin:clamp(1.25rem,1.25rem + 4.2254vw - 25.3524px,1.5rem) 0;padding:clamp(.5rem,1.25rem + 4.2254vw - 25.3524px,2rem);display:inline-flex}@media (width>=992px){.article__image{border-radius:24px;width:calc(100% + 150px);margin-left:-10%;margin-right:-10%}}.article__image-item{border-radius:8px;box-shadow:9px 11px 24px -26px #1b2c41}.article__image-caption{color:#2f445d}.header{flex-direction:column;align-items:center;gap:24px;display:flex}@media (width>=992px){.header{flex-direction:row;gap:32px}}.navigation{flex-flow:wrap;justify-content:center;gap:16px;width:100%;display:flex}@media (width>=992px){.navigation{justify-content:space-between}}.navigation__list{flex-direction:row;align-items:center;margin:0;padding:0;list-style:none;display:flex}.navigation__list-item{margin:0;padding:0}.navigation__list-item-link{border-bottom:0;align-items:center;gap:8px;width:100%;padding:12px;line-height:1.7;display:inline-flex;position:relative}.navigation__list-item-link:hover{background:inherit;color:var(--menu-elements-color-hover)}@media (width>=992px){.navigation__list-item-link{padding:20px}}.navigation__list-item-ico{stroke:currentColor;width:2rem;height:auto}.logo{border-bottom:0;align-items:flex-end;height:80px;display:inline-flex}.logo:hover{background:inherit}.logo:hover .logo__image{fill:var(--menu-elements-color-hover)}.logo:focus-visible{outline-offset:-2px;outline-width:3px;outline-style:dotted;outline-color:var(--border-color)}@media (width>=992px){.logo{height:120px}}.logo__svg{fill:none;height:calc(100% + 20px)}@media (width>=992px){.logo__svg{height:calc(100% + 40px)}}.logo__svg-path{fill:#c7759e}.header__switcher{padding:4px;border:3px solid var(--border-color);user-select:none;border-radius:32px;padding-inline:4px;display:flex}.header__switcher-button{color:var(--text-color);cursor:pointer;background:0 0;border:2px solid #0000;border-radius:32px;margin:0;padding:12px 16px}.header__switcher-button:last-child{border-radius:3px 32px 32px 3px}.header__switcher-button:nth-last-child(2){border-radius:32px 3px 3px 32px}.header__switcher-button[aria-pressed=true]:focus-visible{outline-offset:-7px;outline-width:3px;outline-style:dotted;outline-color:var(--button-text-color)}.header__switcher-button[aria-pressed=false]:focus-visible{outline-offset:-3px;outline-width:3px;outline-style:dotted;outline-color:var(--border-color)}@media (width>=992px){.header__switcher-button{padding:8px 12px}}.header__switcher-button[aria-pressed=true]{color:var(--button-text-color);background:var(--button-bg-color)}.header__switcher-button[aria-pressed=true]:hover{color:var(--button-text-color);background:var(--menu-elements-color-hover)}.header__switcher-button[aria-pressed=false]{color:inherit}.header__switcher-button[aria-pressed=false]:hover{color:var(--button-text-color);background:var(--menu-elements-color-hover)}.footer{flex-wrap:wrap;justify-content:space-between;align-items:flex-end;gap:8px 16px;padding-top:116px;padding-bottom:48px;display:flex}.footer__column{flex-direction:column;justify-content:space-between;gap:8px;display:flex}@media (width>=576px){.footer__column{gap:unset}}.cards{flex-direction:column;gap:20px;width:100%;margin-top:0;padding:0;display:inline-flex}h2:has(+.cards){margin-bottom:clamp(2rem,1.25rem + 4.2254vw - 25.3524px,2.25rem)}.cards:has(+a){margin-bottom:clamp(1.25rem,1.25rem + 4.2254vw - 25.3524px,1.5rem)}@media (width>=768px){.cards--in-article{flex-direction:row}}.cards__item{background:var(--bg-part-color);border-radius:26px;flex-direction:column;justify-content:space-between;gap:16px;width:100%;padding:16px;display:flex;position:relative}.cards__item:before{content:"";position:absolute}.cards__item:hover{background:var(--color-hover)}@media (width>=768px){.cards__item{padding:40px}}.cards__item--compact{padding:20px;display:inline-flex}.cards__item-heading{margin-top:0}.cards__item:focus-within{outline-offset:2px;outline-width:4px;outline-style:dotted;outline-color:var(--border-color)}.cards__item-heading-link:focus-visible,.cards__item-link:focus-visible{outline:0}.cards__item-heading-link,.cards__item-link{color:inherit;border-bottom:0;font-weight:700}.cards__item-heading-link:after,.cards__item-link:after{content:"";position:absolute;inset:0}.cards__item-heading-link:hover,.cards__item-link:hover{color:inherit;background:inherit;border-bottom:0;transition:none}.cards__item-details{align-items:center;gap:8px;display:inline-flex}.cards__item-details__ico{stroke:currentColor;width:1rem;height:auto}.cards__item-description{margin:0}.cards__item-date{align-items:center;gap:4px;display:inline-flex}.topics{flex-wrap:wrap;gap:4px;margin:0;padding:0;list-style:none;display:flex}.topics--in-article{justify-content:center}.topics--in-card{margin-bottom:12px}.topics__item{color:var(--text-color);border:1px solid var(--border-color);border-radius:10px;padding:4px 8px}
\ No newline at end of file
+@media (prefers-reduced-motion:no-preference){a,.header__switcher-button{transition:background .2s}.navigation__list-item-link{transition:color .2s}.cards__item{transition:background .3s}}.base[data-theme=light]{--select-color:#c7759e3a;--bg-color:#c8d5d6;--bg-part-color:#dae3e4;--text-color:#2f445d;--code-color:#b6c7dc;--border-color:#566c87;--color-hover:#b7caca;--menu-elements-color-hover:#65778e;--button-bg-color:#2f445d;--button-text-color:#c8d5d6;--img-filter:unset}.base[data-theme=dark]{--select-color:fuchsia-alpha;--bg-color:#14202f;--bg-part-color:#2f445d;--text-color:#b7caca;--code-color:#2f445d;--border-color:#c8d5d6;--color-hover:#1b2c41;--menu-elements-color-hover:#859ab4;--button-bg-color:#c8d5d6;--button-text-color:#435872;--img-filter:brightness(.8)contrast(1.2)}*,:before,:after{box-sizing:border-box;margin:0}.base{color:var(--text-color);background:var(--bg-color);flex-direction:column;min-height:100vh;margin:0;display:flex}.wrapper{width:100%;max-width:780px;margin:0 auto;padding:0 20px}.base__body{flex:1 0 auto;margin-top:clamp(3.25rem,1.25rem + 4.2254vw - 25.3524px,3.75rem)}@font-face{font-family:IBM Plex Sans;font-style:normal;font-weight:400;font-display:swap;src:url(/fonts/ibm-plex-sans-v8-latin_cyrillic-regular.woff2)format("woff2"),url(/fonts/ibm-plex-sans-v8-latin_cyrillic-regular.woff)format("woff")}@font-face{font-family:IBM Plex Sans;font-style:normal;font-weight:700;font-display:swap;src:url(/fonts/ibm-plex-sans-v8-latin_cyrillic-700.woff2)format("woff2"),url(/fonts/ibm-plex-sans-v8-latin_cyrillic-700.woff)format("woff")}@font-face{font-family:IBM Plex Mono;font-style:normal;font-weight:400;font-display:swap;src:url(/fonts/ibm-plex-mono-v6-latin_cyrillic-regular.woff2)format("woff2"),url(/fonts/ibm-plex-mono-v6-latin_cyrillic-regular.woff)format("woff")}h1{font-size:clamp(2.375rem,1.25rem + 4.2254vw - 25.3524px,2.75rem);line-height:1.318}h2{font-size:clamp(1.75rem,1.25rem + 4.2254vw - 25.3524px,2.125rem);line-height:1.263}h3{font-size:clamp(1.5rem,1.25rem + 4.2254vw - 25.3524px,1.75rem);line-height:1.285}h4{line-height:1.5}samp{font-family:IBM Plex Sans,Arial,Helvetica,sans-serif}small,.cards__item-date,.article-header__dates-item,.article__note-text,.article__image-caption{font-size:clamp(.875rem,1.25rem + 4.2254vw - 25.3524px,1rem)}small,.cards__item-date,.article__note-text,.article__image-caption{line-height:1.5}pre,code,kbd{font-family:IBM Plex Mono,Courier New,monospace;font-size:clamp(1rem,1.25rem + 4.2254vw - 25.3524px,1rem)}.topics__item{font-size:clamp(.875rem,1.25rem + 4.2254vw - 25.3524px,.875rem)}.base{font-family:IBM Plex Sans,Arial,Helvetica,sans-serif;font-size:clamp(1.125rem,1.25rem + 4.2254vw - 25.3524px,1.25rem);line-height:1.6}.visually-hidden{clip:rect(1px,1px,1px,1px);width:1px;height:1px;padding:0;list-style:none;position:absolute;left:0;overflow:hidden}.invisible-anchor{position:relative;top:0}@media (width>=768px){.invisible-anchor{top:-40px}}::selection{background:var(--select-color)}p{margin:clamp(.25rem,1.25rem + 4.2254vw - 25.3524px,.5rem) 0}hr{border:0;width:100%;height:15px;margin:clamp(3rem,1.25rem + 4.2254vw - 25.3524px,3.5rem) auto clamp(1.25rem,1.25rem + 4.2254vw - 25.3524px,1.75rem);display:inline-block;position:relative}hr:after{content:"";background-image:url(../assets/wave.svg);background-position:50%;background-repeat:no-repeat;width:100%;height:15px;display:block;position:absolute;top:0;left:0}ul,ol{margin:0}ul:has(a) li{padding:3px 0}code{word-wrap:break-word;color:var(--text-color);background:var(--code-color);border-radius:4px;padding:4px}a>code{padding-bottom:1px}figure{margin:0;padding:0;display:block}blockquote{border-left:4px solid var(--border-color);word-wrap:break-word;margin:20px 0}blockquote p{padding-left:24px}h1{margin:0 0 clamp(.875rem,1.25rem + 4.2254vw - 25.3524px,1.5rem)}h2{margin:clamp(2.25rem,1.25rem + 4.2254vw - 25.3524px,2.75rem) 0 clamp(.9375rem,1.25rem + 4.2254vw - 25.3524px,1rem)}h3{margin:clamp(2rem,1.25rem + 4.2254vw - 25.3524px,1.75rem) 0 clamp(.875rem,1.25rem + 4.2254vw - 25.3524px,.9375rem)}h4{margin:clamp(1.5rem,1.25rem + 4.2254vw - 25.3524px,1.75rem) 0 clamp(.75rem,1.25rem + 4.2254vw - 25.3524px,.875rem)}a{color:var(--text-color);border-bottom:2px solid var(--border-color);text-decoration:none}a:hover{background:var(--color-hover)}a:focus-visible{outline-offset:2px;outline-width:3px;outline-style:dotted;outline-color:var(--border-color);border-bottom:0}img{max-width:100%;height:auto;display:block}@media (forced-colors:active){::selection{background:highlight}a:hover{color:canvas;background:canvastext}.cards__item{border:2px solid #0000}.cards__item:focus-within{outline-offset:2px;outline:4px dotted #0000}.logo__svg-path{fill:none}}@media (inverted-colors){.wrapper img,.wrapper video{filter:invert()}}.article-header{text-align:center;flex-direction:column;gap:24px;display:flex}.article-header__dates{display:inherit;justify-content:center;gap:24px}.article-header__dates-item{display:inherit;align-items:center;gap:4px}.article-header__dates-item__ico{stroke:currentColor;width:1rem;height:auto}.article{margin-top:clamp(3.25rem,1.25rem + 4.2254vw - 25.3524px,3.75rem)}.article__note{background:var(--bg-part-color);border-radius:8px;align-items:flex-start;gap:16px;margin:clamp(.25rem,1.25rem + 4.2254vw - 25.3524px,2rem) 0;padding:clamp(.5rem,1.25rem + 4.2254vw - 25.3524px,1rem);display:flex}.article__note-text{word-break:break-word;margin:0}.article__note-icon{stroke:currentColor;flex-shrink:0;width:2rem;height:auto;display:inline-flex}.article__code{word-wrap:break-word;background:var(--code-color);border-radius:8px;margin:20px 0;padding:clamp(1rem,1.25rem + 4.2254vw - 25.3524px,1.75rem);display:block;overflow-x:auto}.article__image{filter:var(--img-filter);background:#b3a8db;border-radius:16px;flex-direction:column;gap:20px;width:100%;margin:clamp(1.25rem,1.25rem + 4.2254vw - 25.3524px,1.5rem) 0;padding:clamp(.5rem,1.25rem + 4.2254vw - 25.3524px,2rem);display:inline-flex}@media (width>=992px){.article__image{border-radius:24px;width:calc(100% + 150px);margin-left:-10%;margin-right:-10%}}.article__image-item{border-radius:8px;box-shadow:9px 11px 24px -26px #1b2c41}.article__image-caption{color:#2f445d}.header{flex-direction:column;align-items:center;gap:24px;display:flex}@media (width>=992px){.header{flex-direction:row;gap:32px}}.navigation{flex-flow:wrap;justify-content:center;gap:16px;width:100%;display:flex}@media (width>=992px){.navigation{justify-content:space-between}}.navigation__list{flex-direction:row;align-items:center;margin:0;padding:0;list-style:none;display:flex}.navigation__list-item{margin:0;padding:0}.navigation__list-item-link{border-bottom:0;align-items:center;gap:8px;width:100%;padding:12px;line-height:1.7;display:inline-flex;position:relative}.navigation__list-item-link:hover{background:inherit;color:var(--menu-elements-color-hover)}@media (width>=992px){.navigation__list-item-link{padding:20px}}.navigation__list-item-ico{stroke:currentColor;width:2rem;height:auto}.logo{border-bottom:0;align-items:flex-end;height:80px;display:inline-flex}.logo:hover{background:inherit}.logo:hover .logo__image{fill:var(--menu-elements-color-hover)}.logo:focus-visible{outline-offset:-2px;outline-width:3px;outline-style:dotted;outline-color:var(--border-color)}@media (width>=992px){.logo{height:120px}}.logo__svg{fill:none;height:calc(100% + 20px)}@media (width>=992px){.logo__svg{height:calc(100% + 40px)}}.logo__svg-path{fill:#c7759e}.header__switcher{padding:4px;border:3px solid var(--border-color);user-select:none;border-radius:32px;padding-inline:4px;display:flex}.header__switcher-button{color:var(--text-color);cursor:pointer;background:0 0;border:2px solid #0000;border-radius:32px;margin:0;padding:12px 16px}.header__switcher-button:last-child{border-radius:3px 32px 32px 3px}.header__switcher-button:nth-last-child(2){border-radius:32px 3px 3px 32px}.header__switcher-button[aria-pressed=true]:focus-visible{outline-offset:-7px;outline-width:3px;outline-style:dotted;outline-color:var(--button-text-color)}.header__switcher-button[aria-pressed=false]:focus-visible{outline-offset:-3px;outline-width:3px;outline-style:dotted;outline-color:var(--border-color)}@media (width>=992px){.header__switcher-button{padding:8px 12px}}.header__switcher-button[aria-pressed=true]{color:var(--button-text-color);background:var(--button-bg-color)}.header__switcher-button[aria-pressed=true]:hover{color:var(--button-text-color);background:var(--menu-elements-color-hover)}.header__switcher-button[aria-pressed=false]{color:inherit}.header__switcher-button[aria-pressed=false]:hover{color:var(--button-text-color);background:var(--menu-elements-color-hover)}.footer{flex-wrap:wrap;justify-content:space-between;align-items:flex-end;gap:16px;padding-top:116px;padding-bottom:48px;display:flex}.footer__column{flex-direction:column;justify-content:space-between;gap:8px;display:flex}@media (width>=576px){.footer__column{gap:unset}}.cards{flex-direction:column;gap:20px;width:100%;margin-top:0;padding:0;display:inline-flex}h2:has(+.cards){margin-bottom:clamp(2rem,1.25rem + 4.2254vw - 25.3524px,2.25rem)}.cards:has(+a){margin-bottom:clamp(1.25rem,1.25rem + 4.2254vw - 25.3524px,1.5rem)}@media (width>=768px){.cards--in-article{flex-direction:row}}.cards__item{background:var(--bg-part-color);border-radius:26px;flex-direction:column;justify-content:space-between;gap:16px;width:100%;padding:16px;display:flex;position:relative}.cards__item:before{content:"";position:absolute}.cards__item:hover{background:var(--color-hover)}@media (width>=768px){.cards__item{padding:40px}}.cards__item--compact{padding:20px;display:inline-flex}.cards__item-heading{margin-top:0}.cards__item:focus-within{outline-offset:2px;outline-width:4px;outline-style:dotted;outline-color:var(--border-color)}.cards__item-heading-link:focus-visible,.cards__item-link:focus-visible{outline:0}.cards__item-heading-link,.cards__item-link{color:inherit;border-bottom:0;font-weight:700}.cards__item-heading-link:after,.cards__item-link:after{content:"";position:absolute;inset:0}.cards__item-heading-link:hover,.cards__item-link:hover{color:inherit;background:inherit;border-bottom:0;transition:none}.cards__item-details{align-items:center;gap:8px;display:inline-flex}.cards__item-details__ico{stroke:currentColor;width:1rem;height:auto}.cards__item-description{margin:0}.cards__item-date{align-items:center;gap:4px;display:inline-flex}.topics{flex-wrap:wrap;gap:4px;margin:0;padding:0;list-style:none;display:flex}.topics--in-article{justify-content:center}.topics--in-card{margin-bottom:12px}.topics__item{color:var(--text-color);border:1px solid var(--border-color);border-radius:10px;padding:4px 8px}
\ No newline at end of file
diff --git a/styles/styles.css.map b/styles/styles.css.map
index 4c4319b..74b6554 100644
--- a/styles/styles.css.map
+++ b/styles/styles.css.map
@@ -1 +1 @@
-{"version":3,"sourceRoot":"","sources":["../../src/styles/basic/_animation.scss","../../src/styles/basic/_color-themes.scss","../../src/styles/basic/_layout.scss","../../src/styles/basic/_fonts.scss","../../src/styles/basic/_typography.scss","../../src/styles/basic/_global.scss","../../src/styles/_mixins-and-functions.scss","../../src/styles/basic/_text.scss","../../src/styles/_variables.scss","../../src/styles/basic/_links.scss","../../src/styles/basic/_images.scss","../../src/styles/basic/_contrast-and-inverted-colors.scss","../../src/styles/components/_article.scss","../../src/styles/components/_header.scss","../../src/styles/components/_menu.scss","../../src/styles/components/_logo.scss","../../src/styles/components/_theme-switcher.scss","../../src/styles/components/_footer.scss","../../src/styles/components/_card.scss","../../src/styles/components/_tags.scss"],"names":[],"mappings":"AAAA;EACC;IACC;;EAGD;IACC;;EAGD;IACC;;EAGD;IACC;;;ACZF;EACC;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;;;AAGD;EACC;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;;;ACxBD;EACC;EACA;;;AAGD;EACC;EACA;EACA;EACA;EACA;EACA;;;AAGD;EACC;EACA;EACA;EACA;;;AAGD;EACC;EACA;;;ACzBD;EACC;EACA;EACA;EACA;EACA;;AAKD;EACC;EACA;EACA;EACA;EACA;;AAKD;EACC;EACA;EACA;EACA;EACA;;ACDD;EACC;EACA,aAlBgB;;;AAqBjB;EACC;EACA,aAtBgB;;;AAyBjB;EACC;EACA,aA1BgB;;;AA6BjB;EACC,aA7BgB;;;AAgCjB;EACC,aAzCkB;;;AA4CnB;AAAA;AAAA;AAAA;AAAA;EAKC;;;AAID;AAAA;AAAA;AAAA;EAIC,aAjDgB;;;AAoDjB;AAAA;AAAA;EAGC,aA9DkB;EA+DlB;;;AAGD;EACC;;;AAGD;EACC,aAxEkB;EAyElB;EACA,aAtEkB;;;ACLnB;EACC;EACA;EACA;EACA;EACA;EACA;EACA;EACA;;;AAGD;EACC;EACA;;ACVA;EDQD;IAKE;;;;AEdF;EACC;;;AAGD;EACC;;;AAGD;EACC;EACA;EACA;EACA,QAdW;EAeX;EACA;;AAEA;EACC;EACA;EACA;EACA;EACA;EACA;EACA,QAzBU;EA0BV;EACA;EACA;;;AAIF;AAAA;EAEC;;;AAGD;EACC;;;AAGD;EACC,SCMO;EDLP;EACA;EACA;EACA,eCPU;;;ADUX;EACC;;;AAGD;EACC;EACA;EACA;;;AAGD;EACC;EACA;EACA;;;AAGD;EACC,cCvCQ;;;AD0CT;EACC;;;AAGD;EACC;;;AAGD;EACC;;;AAGD;EACC;;;AEnFD;EACC;EACA;EACA;;AAEA;EACC;;AAGD;EHEA,eADoB;EAEpB,gBGDW;EHEX,eAHuE;EAIvE,eAJ0C;EGGzC;;;ACfF;EACC;EACA;EACA;;;ACAD;EACC;IACC;;EAGD;IACC;IACA;;EAGD;IACC;;EAGD;ILJA,eKMU;ILLV,gBKMW;ILLX,eAHuE;IAIvE,eKKU;;EAIV;IACC;;;AAKF;EACC;AAAA;IAEC;;;AC/BF;EACC;EACA;EACA;EACA,KJmDQ;;;AIhDT;EACC;EACA;EACA,KJ6CQ;;;AI1CT;EACC;EACA;EACA,KJgCO;;;AI7BR;EACC;EACA;EACA;;;AAGD;EACC;;;AAGD;EACC;EACA;EACA;EACA;EACA,KJmBQ;EIlBR;EACA,eJIU;;;AIDX;EACC;EACA;;;AAGD;EACC;EACA;EACA;EACA;EACA;;;AAGD;EACC;EACA;EACA;EACA;EACA;EACA,eJlBU;EImBV;;;AAGD;EACC;EACA;EACA;EACA;EACA;EACA,KJdQ;EIeR,YJvDgB;EIwDhB,eJ5BW;EI6BX;;ANpEA;EM2DD;IAYE;IACA;IACA;IACA,eJlCU;;;;AIsCZ;EACC;EACA,eJ3CU;;;AI8CX;EACC,OJ9EQ;;;AKTT;EACC;EACA;EACA;EACA,KLuBQ;;AFxBR;EOHD;IAOE;IACA,KLqBO;;;;AM3BT;EACC;EACA;EACA;EACA;EACA;EACA,KNiBQ;;AFtBR;EQDD;IASE;;;;AAIF;EACC;EACA;EACA;EACA;EACA;EACA;;;AAGD;EACC;EACA;;;AAGD;EACC;EACA;EACA;EACA;EACA,SNVQ;EMWR,KNZQ;EMaR,aApCuB;EAqCvB;;AAEA;EACC;EACA;;ARtCD;EQ0BD;IAgBE,SNnBO;;;;AMuBT;EACC;EACA;EACA;;;ACpDD;EACC;EACA;EACA;EACA;;AAEA;EACC;;AAGD;EACC;;AAGD;ETJA,eADoB;EAEpB,gBSKW;ETJX,eAHuE;EAIvE,eAJ0C;;AAN1C;ESHD;IAqBE;;;;AAIF;EACC;EACA;;ATxBA;ESsBD;IAKE;;;;AAIF;EACC;;;ACnCD;EACC;EACA,SRoBQ;EQnBR,gBRmBQ;EQlBR;EACA,eRwCW;EQvCX;;;AAGD;EACC;EACA;EACA;EACA,eRgCW;EQ/BX;EACA;EACA;;AAEA;EACC;;AAGD;EACC;;AAGD;EVhBA,eADoB;EAEpB,gBUiBW;EVhBX,eAHuE;EAIvE,eUgBU;;AAIV;EVvBA,eADoB;EAEpB,gBUwBW;EVvBX,eAHuE;EAIvE,eAJ0C;;AAN1C;EUMD;IA+BE;;;;AAIF;EACC;EACA;;AAEA;EACC;EACA;;;AAIF;EACC;;AAEA;EACC;EACA;;;AC3DF;EACC;EACA;EACA;EACA;EACA;EACA,aT8BS;ES7BT,gBTyBS;;;AStBV;EACC;EACA;EACA;EACA,KTSQ;;AFpBR;EWOD;IAOE;;;;ACjBF;EACC;EACA;EACA;EACA;EACA;EACA,KVoBQ;;;AUjBT;EACC;;;AAGD;EACC;;;AZXA;EYcD;IAEE;;;;AAIF;EACC;EACA;EACA;EACA;EACA;EACA,SVJQ;EUKR,KVLQ;EUMR;EACA,eVYW;;AUVX;EACC;EACA;;AAGD;EACC;;AZrCD;EYoBD;IAqBE,SVbQ;;;;AUiBV;EACC;EACA,SVxBQ;;;AU2BT;EACC;;;AAGD;EZ/CC,eYiDS;EZhDT,gBYiDU;EZhDV,eAHuE;EAIvE,eAJ0C;;;AYuD3C;AAAA;EAEC;;;AAGD;AAAA;EAEC;EACA;EACA;;AAEA;AAAA;EACC;EACA;EACA;EACA;EACA;EACA;;AAGD;AAAA;EACC;EACA;EACA;EACA;;;AAIF;EACC;EACA;EACA,KVxEQ;;;AU2ET;EACC;EACA;EACA;;;AAGD;EACC;;;AAGD;EACC;EACA;EACA,KVzFQ;;;AWvBT;EACC;EACA;EACA;EACA;EACA,KXkBQ;EWjBR;;;AAGD;EACC;;;AAGD;EACC,eXWQ;;;AWRT;EACC;EACA;EACA;EACA,eXqBW","file":"styles.css"}
\ No newline at end of file
+{"version":3,"sourceRoot":"","sources":["../../src/styles/basic/_animation.scss","../../src/styles/basic/_color-themes.scss","../../src/styles/basic/_layout.scss","../../src/styles/basic/_fonts.scss","../../src/styles/basic/_typography.scss","../../src/styles/basic/_global.scss","../../src/styles/_mixins-and-functions.scss","../../src/styles/basic/_text.scss","../../src/styles/_variables.scss","../../src/styles/basic/_links.scss","../../src/styles/basic/_images.scss","../../src/styles/basic/_contrast-and-inverted-colors.scss","../../src/styles/components/_article.scss","../../src/styles/components/_header.scss","../../src/styles/components/_menu.scss","../../src/styles/components/_logo.scss","../../src/styles/components/_theme-switcher.scss","../../src/styles/components/_footer.scss","../../src/styles/components/_card.scss","../../src/styles/components/_tags.scss"],"names":[],"mappings":"AAAA;EACC;IACC;;EAGD;IACC;;EAGD;IACC;;EAGD;IACC;;;ACZF;EACC;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;;;AAGD;EACC;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;;;ACxBD;EACC;EACA;;;AAGD;EACC;EACA;EACA;EACA;EACA;EACA;;;AAGD;EACC;EACA;EACA;EACA;;;AAGD;EACC;EACA;;;ACzBD;EACC;EACA;EACA;EACA;EACA;;AAKD;EACC;EACA;EACA;EACA;EACA;;AAKD;EACC;EACA;EACA;EACA;EACA;;ACDD;EACC;EACA,aAlBgB;;;AAqBjB;EACC;EACA,aAtBgB;;;AAyBjB;EACC;EACA,aA1BgB;;;AA6BjB;EACC,aA7BgB;;;AAgCjB;EACC,aAzCkB;;;AA4CnB;AAAA;AAAA;AAAA;AAAA;EAKC;;;AAID;AAAA;AAAA;AAAA;EAIC,aAjDgB;;;AAoDjB;AAAA;AAAA;EAGC,aA9DkB;EA+DlB;;;AAGD;EACC;;;AAGD;EACC,aAxEkB;EAyElB;EACA,aAtEkB;;;ACLnB;EACC;EACA;EACA;EACA;EACA;EACA;EACA;EACA;;;AAGD;EACC;EACA;;ACVA;EDQD;IAKE;;;;AEdF;EACC;;;AAGD;EACC;;;AAGD;EACC;EACA;EACA;EACA,QAdW;EAeX;EACA;;AAEA;EACC;EACA;EACA;EACA;EACA;EACA;EACA,QAzBU;EA0BV;EACA;EACA;;;AAIF;AAAA;EAEC;;;AAGD;EACC;;;AAGD;EACC,SCnBO;EDoBP;EACA;EACA;EACA,eCHU;;;ADMX;EACC;;;AAGD;EACC;EACA;EACA;;;AAGD;EACC;EACA;EACA;;;AAGD;EACC,cCpCQ;;;ADuCT;EACC;;;AAGD;EACC;;;AAGD;EACC;;;AAGD;EACC;;;AEnFD;EACC;EACA;EACA;;AAEA;EACC;;AAGD;EHEA,eADoB;EAEpB,gBGDW;EHEX,eAHuE;EAIvE,eAJ0C;EGGzC;;;ACfF;EACC;EACA;EACA;;;ACAD;EACC;IACC;;EAGD;IACC;IACA;;EAGD;IACC;;EAGD;ILJA,eKMU;ILLV,gBKMW;ILLX,eAHuE;IAIvE,eKKU;;EAIV;IACC;;;AAKF;EACC;AAAA;IAEC;;;AC/BF;EACC;EACA;EACA;EACA,KJ0BQ;;;AIvBT;EACC;EACA;EACA,KJoBQ;;;AIjBT;EACC;EACA;EACA,KJOO;;;AIJR;EACC;EACA;EACA;;;AAGD;EACC;;;AAGD;EACC;EACA;EACA;EACA;EACA,KJNQ;EIOR;EACA,eJQU;;;AILX;EACC;EACA;;;AAGD;EACC;EACA;EACA;EACA;EACA;;;AAGD;EACC;EACA;EACA;EACA;EACA;EACA,eJdU;EIeV;;;AAGD;EACC;EACA;EACA;EACA;EACA;EACA,KJvCQ;EIwCR,YJvDgB;EIwDhB,eJxBW;EIyBX;;ANpEA;EM2DD;IAYE;IACA;IACA;IACA,eJ9BU;;;;AIkCZ;EACC;EACA,eJvCU;;;AI0CX;EACC,OJ9EQ;;;AKTT;EACC;EACA;EACA;EACA,KL0BQ;;AF3BR;EOHD;IAOE;IACA,KLwBO;;;;AM9BT;EACC;EACA;EACA;EACA;EACA;EACA,KNoBQ;;AFzBR;EQDD;IASE;;;;AAIF;EACC;EACA;EACA;EACA;EACA;EACA;;;AAGD;EACC;EACA;;;AAGD;EACC;EACA;EACA;EACA;EACA,SNTQ;EMUR,KNXO;EMYP,aApCuB;EAqCvB;;AAEA;EACC;EACA;;ARtCD;EQ0BD;IAgBE,SNhBO;;;;AMoBT;EACC;EACA;EACA;;;ACpDD;EACC;EACA;EACA;EACA;;AAEA;EACC;;AAGD;EACC;;AAGD;ETJA,eADoB;EAEpB,gBSKW;ETJX,eAHuE;EAIvE,eAJ0C;;AAN1C;ESHD;IAqBE;;;;AAIF;EACC;EACA;;ATxBA;ESsBD;IAKE;;;;AAIF;EACC;;;ACnCD;EACC;EACA,SRqBO;EQpBP,gBRoBO;EQnBP;EACA,eR4CW;EQ3CX;;;AAGD;EACC;EACA;EACA;EACA,eRoCW;EQnCX;EACA;EACA;;AAEA;EACC;;AAGD;EACC;;AAGD;EVhBA,eADoB;EAEpB,gBUiBW;EVhBX,eAHuE;EAIvE,eUgBU;;AAIV;EVvBA,eADoB;EAEpB,gBUwBW;EVvBX,eAHuE;EAIvE,eAJ0C;;AAN1C;EUMD;IA+BE;;;;AAIF;EACC;EACA;;AAEA;EACC;EACA;;;AAIF;EACC;;AAEA;EACC;EACA;;;AC3DF;EACC;EACA;EACA;EACA;EACA,aTmCS;ESlCT,gBT8BQ;ES7BR,KTqBQ;;;ASlBT;EACC;EACA;EACA;EACA,KTUO;;AFrBP;EWOD;IAOE;;;;ACjBF;EACC;EACA;EACA;EACA;EACA;EACA,KVuBQ;;;AUpBT;EACC;;;AAGD;EACC;;;AZXA;EYcD;IAEE;;;;AAIF;EACC;EACA;EACA;EACA;EACA;EACA,SVDQ;EUER,KVFQ;EUGR;EACA,eVgBW;;AUdX;EACC;EACA;;AAGD;EACC;;AZrCD;EYoBD;IAqBE,SVVO;;;;AUcT;EACC;EACA,SVrBQ;;;AUwBT;EACC;;;AAGD;EZ/CC,eYiDS;EZhDT,gBYiDU;EZhDV,eAHuE;EAIvE,eAJ0C;;;AYuD3C;AAAA;EAEC;;;AAGD;AAAA;EAEC;EACA;EACA;;AAEA;AAAA;EACC;EACA;EACA;EACA;EACA;EACA;;AAGD;AAAA;EACC;EACA;EACA;EACA;;;AAIF;EACC;EACA;EACA,KVvEO;;;AU0ER;EACC;EACA;EACA;;;AAGD;EACC;;;AAGD;EACC;EACA;EACA,KVxFO;;;AWxBR;EACC;EACA;EACA;EACA;EACA,KXmBO;EWlBP;;;AAGD;EACC;;;AAGD;EACC,eXYQ;;;AWTT;EACC;EACA;EACA;EACA,eXyBW","file":"styles.css"}
\ No newline at end of file