From 4cfb15f283b7f0e6f121ce78783186fd74a47306 Mon Sep 17 00:00:00 2001 From: TatianaFokina Date: Thu, 27 Jun 2024 01:21:06 +0400 Subject: [PATCH] Updates --- en/404/index.html | 2 +- en/articles/aria-attribute-role-with-multiple-values/index.html | 2 +- en/articles/aria-live-regions/index.html | 2 +- en/articles/css-media-features-for-a11y/index.html | 2 +- .../how-to-protect-users-with-epilepsy-and-vd/index.html | 2 +- en/articles/index.html | 2 +- en/articles/understanding-a-skip-link/index.html | 2 +- en/index.html | 2 +- ru/404/index.html | 2 +- ru/articles/aria-attribute-role-with-multiple-values/index.html | 2 +- ru/articles/css-media-features-for-a11y/index.html | 2 +- .../how-to-protect-users-with-epilepsy-and-vd/index.html | 2 +- ru/articles/index.html | 2 +- ru/articles/understanding-a-skip-link/index.html | 2 +- ru/articles/wcag-character-key/index.html | 2 +- ru/articles/wcag-consistent-identification/index.html | 2 +- ru/articles/wcag-focus-appearance/index.html | 2 +- ru/articles/wcag-focus-visible/index.html | 2 +- ru/articles/wcag-info-and-relationships/index.html | 2 +- ru/articles/wcag-keyboard/index.html | 2 +- ru/articles/wcag-non-text-content/index.html | 2 +- ru/articles/wcag-page-titled/index.html | 2 +- ru/articles/wcag-sensory-characteristics/index.html | 2 +- ru/articles/wcag-target-size/index.html | 2 +- ru/index.html | 2 +- styles/styles.css | 2 +- styles/styles.css.map | 2 +- 27 files changed, 27 insertions(+), 27 deletions(-) diff --git a/en/404/index.html b/en/404/index.html index 260e540..75ad51a 100644 --- a/en/404/index.html +++ b/en/404/index.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

\ 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

\ 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 cf274dc..67ed03d 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-03T00:00:00.000Z" - }

Role attribute with multiple values

  • ARIA
  • HTML

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
 
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 456ee47..f9ecc96 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-05-11T00:00:00.000Z"
-		}
 
Everything you need to know about ARIA Live Regions
  • HTML
  • Screen readers
 
(This is a translation of my article from Web Standarts, editor Vadim Makeev)
How to make content changes accessible.
If you have a dynamically changing part of a page and you're thinking about making it accessible, there may be a legitimate question about how to make it so. These could be:
  • Chats;
  • Progress bars and timers;
  • Widgets with news and weather forecasts;
  • Miscellaneous bugs and alerts: new post, like, subscribe;
  • Tickers (stock exchange information about stock quotes, indices, bonds), currency rates;
  • Sports statistics and much more.
Previously, assistive technologies (including screen readers) didn't know how to properly process these. Users couldn't know if there was an error or new data until they returned to the previous block or reached the end of the page. Now the problem of accessibility of dynamically changing page content can be solved with ARIA.
If you're not familiar with this acronym, WAI-ARIA (Web Accessibility Initiative - Accessible Rich Internet Applications) or simply ARIA is a standard consisting of a set of special roles and attributes that are added to markup and extend or augment the functions of standard HTML elements.
All we need to do is make the part of the page where the changes occur. In ARIA terminology, this is called a "live region." You can find this definition in the standard:
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, the main purpose of such areas is to tell screen readers how to properly handle content changes that aren't necessarily dependent on users.
To make an interactive area on a page, we just need to add the aria-live="" attribute or a special ARIA role to any parent element. Then the changes of all its child elements will become available to screen readers. They will know now how to handle updates to the contents of such elements.
There are several such roles and attributes in ARIA. Let's talk about the roles first.
Interactive Area Roles
There aren't many ARIA roles that make part of a page an interactive area. They are used like this: role="alert" Here's a complete list of them:
  • alert;
  • status;
  • log;
  • timer;
  • marquee.
Let's deal with each role in order.
Alert
A type of interactive area that contains information that is important at a certain point in time. It can be an error message, a warning that appears on the screen after some user actions or without his participation (a sudden error on the server side). Such a message can be either text or sound.
Let's take a look at a simple example where we warn users about something really important:
<div class="warning" role="alert">
+		}
 
Everything you need to know about ARIA Live Regions
  • HTML
  • Screen readers
 
(This is a translation of my article from Web Standarts, editor Vadim Makeev)
How to make content changes accessible.
If you have a dynamically changing part of a page and you're thinking about making it accessible, there may be a legitimate question about how to make it so. These could be:
  • Chats;
  • Progress bars and timers;
  • Widgets with news and weather forecasts;
  • Miscellaneous bugs and alerts: new post, like, subscribe;
  • Tickers (stock exchange information about stock quotes, indices, bonds), currency rates;
  • Sports statistics and much more.
Previously, assistive technologies (including screen readers) didn't know how to properly process these. Users couldn't know if there was an error or new data until they returned to the previous block or reached the end of the page. Now the problem of accessibility of dynamically changing page content can be solved with ARIA.
If you're not familiar with this acronym, WAI-ARIA (Web Accessibility Initiative - Accessible Rich Internet Applications) or simply ARIA is a standard consisting of a set of special roles and attributes that are added to markup and extend or augment the functions of standard HTML elements.
All we need to do is make the part of the page where the changes occur. In ARIA terminology, this is called a "live region." You can find this definition in the standard:
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, the main purpose of such areas is to tell screen readers how to properly handle content changes that aren't necessarily dependent on users.
To make an interactive area on a page, we just need to add the aria-live="" attribute or a special ARIA role to any parent element. Then the changes of all its child elements will become available to screen readers. They will know now how to handle updates to the contents of such elements.
There are several such roles and attributes in ARIA. Let's talk about the roles first.
Interactive Area Roles
There aren't many ARIA roles that make part of a page an interactive area. They are used like this: role="alert" Here's a complete list of them:
  • alert;
  • status;
  • log;
  • timer;
  • marquee.
Let's deal with each role in order.
Alert
A type of interactive area that contains information that is important at a certain point in time. It can be an error message, a warning that appears on the screen after some user actions or without his participation (a sudden error on the server side). Such a message can be either text or sound.
Let's take a look at a simple example where we warn users about something really important:
<div class="warning" role="alert">
     You've stared into the abyss for too long,
     and now the abyss is staring back at you.
 </div>
Screen reader will instantly announce it the moment it appears, and interrupt the other announcement if there is one.
👉 For maximum compatibility, use role="alert" together with the aria-live="assertive" attribute. That said, such an element can still be incorrectly declared by VoiceOver on iOS. Let's make some minor changes to our example:
<div class="warning" role="alert" aria-live="assertive">
diff --git a/en/articles/css-media-features-for-a11y/index.html b/en/articles/css-media-features-for-a11y/index.html
index c67da18..c24d6f7 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-05-09T00:00:00.000Z"
-		}
 
CSS media feature to improve accessibility
  • CSS
  • Usability
 
When people talk about accessibility and CSS, they often mean properties that affect the accessibility tree and screen readers. But there's another ally in the battle for accessibility interfaces — media features.
Media feature is a condition for the @media CSS directive. It indicates a specific characteristic 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-colour-scheme, inverted-colors, forced-colors, ms-high-contrast, prefers-contrast and prefers-reduced-transparency. They track operating system settings. The settings are changed by users who aren't satisfied with the default behaviour of the system. For example, people with special needs and those who are uncomfortable with the default design.
For example, users with epileptic seizures disable animations because they can trigger a seizure. Some people with astigmatism choose a dark theme and reduce contrast to avoid eye pain.
Considering user preferences will make the site's interface more flexible and personalised. This will not only help improve its accessibility but can also increase conversion rates. It's always nice to use products that cater to your preferences.
Most customisations apply only to the operating system. Many of them, the same 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 bloat this post any further. I'll just focus on CSS features.
Custom Settings
Let's first look at what system settings can be considered in web interfaces now or in the future.
Animation
Animation settings allow you to change its speed or disable it completely in the system. Does not affect sites unless there are special styles.
Who uses the setting:
  • Users with vestibular disorders and epileptic seizures.
  • People with cognitive disabilities. Especially users with attention deficit disorder.
This setting is found in most operating systems.
Colour scheme
Users can also change the colour scheme settings and select the colours that will dominate the system. These are either light or dark shades. The setting does not affect sites if they do not support colour schemes.
Who uses the setting:
  • People with visual impairments. For example, people with reduced vision, eye pain, and hypersensitivity to light.
  • Users with cognitive disabilities. For example, with attention deficit disorder.
  • All other users due to aesthetic preferences, habits or light levels.
Schemes can be selected in all popular operating systems. In macOS and iOS, there is an optional automatic theme. If selected, a light theme is applied during the day and a dark theme at night.
Invert Colours
Inverted colours mode replaces the system colours with opposite colours, as in the negative. It refers to the on-screen filter mode.
Colours are changed not only in the system but also in browser tabs. So users can choose this mode instead of dark theme.
In inversion mode, yellow shades became blue, green became crimson, and white became black.
Doka guide with inversion in Vivaldi on Windows 10.
Who uses the setting:
  • People with visual impairments. For example, people with glaucoma or eye pain.
  • People with migraines and headaches.
  • Other users because of habits or lighting.
Most operating systems have this setting. On iOS, there are even two types of inversion, Smart Invert and Classic Invert. In Smart Invert, pictures and videos are not inverted. In Classic Invert, all content is inverted.
Colour mode
The forced colours mode limits the number of colours to increase the readability of text by changing the contrast between text and background. Colours with high contrast are mainly used. This mode changes the colours in both the system and sites.
Who uses the setting:
  • People with visual impairments.
  • People with migraines and headaches.
  • People with photosensitive epilepsy.
  • Users who need to reduce visual noise to concentrate.
For now, the colour mode can only be selected in Windows. In Windows 10 and earlier, it's Windows High Contrast Mode (WHCM for short). In Windows 11, it's Contrast Themes.
High Contrast Mode has several ready-made colour sets:
  • High Contrast Black mode;
  • High Contrast White;
  • High Contrast 1 and 2.
The colour palette replacement technology depends on the browser. It differs in Chromium, Firefox (Quantum), Internet Explorer (Trident) and older versions of Edge (EdgeHTML).
Section with podcast episodes from the Web Standards home page with system colours. White background became black, links and borders are bright yellow, and plain text is white instead of dark grey.
"Web Standards" with high contrast black mode in Vivaldi on Windows 10.
Section with podcast episodes from the Web Standards home page with system colours. The white background remains the same colour, the links and borders are now bright blue, and the plain text is black instead of dark grey.
This is how Firefox's default high-contrast black mode on Windows 10 is interpreted. The default behaviour can be changed. You need to select the "Use system colours" option in the Language and Appearance settings.
In Windows 11, the set of contrasting themes has changed:
  • Aquatic.
  • Desert.
  • Dusk.
  • Night sky.
Section with podcast episodes from the Web Standards home page with system colours. White background became black, links and borders are purple, and plain text is white instead of dark grey.
"Web Standards" in Night Sky Mode in Vivaldi on Windows 11.
If the ready-made themes are not suitable, you can customise them yourself. This includes reducing the contrast.
Contrast
Users can separately increase or decrease the contrast level in the system without changing the screen brightness.
Who uses the setting:
  • People with visual impairments. For example, people with glaucoma.
  • People with migraines and headaches.
  • Users with old or poor-quality displays.
  • Other users who lack contrast levels due to lighting.
macOS and iOS have an Increased Contrast Mode. It increases the difference between shades of grey and makes the borders of elements clearer.
Settings affect the appearance of the system and web interfaces. Unlike system windows, only the contrast level is changed on websites. Of course, the borders of elements do not become clearer by themselves.
Comparing windows in normal mode and contrast-enhanced mode in macOS. In both windows, a picture of a screaming cat called «cute-cat.jpeg» is open. You can see controls for closing, expanding, zooming in and out, as well as additional settings.
In the high contrast mode, strangely enough, everything became more contrasty. Black frames appeared around the window and controls.
Transparency
Users can switch background transparency on or off. Opaque backgrounds are often chosen by those who want to increase contrast.
A transparent background can increase cognitive load and reduce the readability of text. Therefore, this setting is used by:
  • People with visual impairments. For example, with astigmatism or reduced vision.
  • Users with cognitive disabilities. For example, people with dyslexia or attention deficit disorder.
  • People with migraines and headaches.
Transparency is customisable on Windows and macOS.
These settings only affect transparency in the system interface.
Comparison of windows with and without transparency setting enabled in Windows. Both with system screen settings. The window has a navigation bar on the left and settings on the right.
This is how the transparency setting works in Windows 10. The navigation background of the first window is semi-transparent, and the second one is opaque and monochrome.
A word about media types
The @media directive has several media types. They describe the device on which the document is displayed.
  • all. All devices. It is set automatically if no other type is specified.
  • screen. Devices with screens. For example, phones and laptops.
  • print. Devices with preview and print functions. The same as 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. So far it is not supported by browsers. It used to be supported by Opera browser on Presto engine but stopped after switching to Blink.
In the future, it may be useful for special styles for screen readers. For example, to apply CSS properties for speech synthesis devices to necessary elements.
Media Features
And now let's move on to media features that help to make web interfaces more accessible.
Some of them don't have very impressive support yet. Something may change in the future with the development of CSS. In any case, it's good to know about them. You might even want to experiment with these media features in a small pet project now.
prefer-reduced-motion
Tracks whether animation settings are selected to reduce animation intensity.
There are two values:
  • no-preference, the default animation settings.
  • reduce, the modified animation settings.
Prefers-reduced-motion has good browser support at 91.75%.
It can be useful for any animation on the site. You can slow it down or disable it completely.
Setting animation: none to elements with animation will stop it completely.
@media (prefers-reduced-motion: reduce) {
+		}
 
CSS media feature to improve accessibility
  • CSS
  • Usability
 
When people talk about accessibility and CSS, they often mean properties that affect the accessibility tree and screen readers. But there's another ally in the battle for accessibility interfaces — media features.
Media feature is a condition for the @media CSS directive. It indicates a specific characteristic 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-colour-scheme, inverted-colors, forced-colors, ms-high-contrast, prefers-contrast and prefers-reduced-transparency. They track operating system settings. The settings are changed by users who aren't satisfied with the default behaviour of the system. For example, people with special needs and those who are uncomfortable with the default design.
For example, users with epileptic seizures disable animations because they can trigger a seizure. Some people with astigmatism choose a dark theme and reduce contrast to avoid eye pain.
Considering user preferences will make the site's interface more flexible and personalised. This will not only help improve its accessibility but can also increase conversion rates. It's always nice to use products that cater to your preferences.
Most customisations apply only to the operating system. Many of them, the same 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 bloat this post any further. I'll just focus on CSS features.
Custom Settings
Let's first look at what system settings can be considered in web interfaces now or in the future.
Animation
Animation settings allow you to change its speed or disable it completely in the system. Does not affect sites unless there are special styles.
Who uses the setting:
  • Users with vestibular disorders and epileptic seizures.
  • People with cognitive disabilities. Especially users with attention deficit disorder.
This setting is found in most operating systems.
Colour scheme
Users can also change the colour scheme settings and select the colours that will dominate the system. These are either light or dark shades. The setting does not affect sites if they do not support colour schemes.
Who uses the setting:
  • People with visual impairments. For example, people with reduced vision, eye pain, and hypersensitivity to light.
  • Users with cognitive disabilities. For example, with attention deficit disorder.
  • All other users due to aesthetic preferences, habits or light levels.
Schemes can be selected in all popular operating systems. In macOS and iOS, there is an optional automatic theme. If selected, a light theme is applied during the day and a dark theme at night.
Invert Colours
Inverted colours mode replaces the system colours with opposite colours, as in the negative. It refers to the on-screen filter mode.
Colours are changed not only in the system but also in browser tabs. So users can choose this mode instead of dark theme.
In inversion mode, yellow shades became blue, green became crimson, and white became black.
Doka guide with inversion in Vivaldi on Windows 10.
Who uses the setting:
  • People with visual impairments. For example, people with glaucoma or eye pain.
  • People with migraines and headaches.
  • Other users because of habits or lighting.
Most operating systems have this setting. On iOS, there are even two types of inversion, Smart Invert and Classic Invert. In Smart Invert, pictures and videos are not inverted. In Classic Invert, all content is inverted.
Colour mode
The forced colours mode limits the number of colours to increase the readability of text by changing the contrast between text and background. Colours with high contrast are mainly used. This mode changes the colours in both the system and sites.
Who uses the setting:
  • People with visual impairments.
  • People with migraines and headaches.
  • People with photosensitive epilepsy.
  • Users who need to reduce visual noise to concentrate.
For now, the colour mode can only be selected in Windows. In Windows 10 and earlier, it's Windows High Contrast Mode (WHCM for short). In Windows 11, it's Contrast Themes.
High Contrast Mode has several ready-made colour sets:
  • High Contrast Black mode;
  • High Contrast White;
  • High Contrast 1 and 2.
The colour palette replacement technology depends on the browser. It differs in Chromium, Firefox (Quantum), Internet Explorer (Trident) and older versions of Edge (EdgeHTML).
Section with podcast episodes from the Web Standards home page with system colours. White background became black, links and borders are bright yellow, and plain text is white instead of dark grey.
"Web Standards" with high contrast black mode in Vivaldi on Windows 10.
Section with podcast episodes from the Web Standards home page with system colours. The white background remains the same colour, the links and borders are now bright blue, and the plain text is black instead of dark grey.
This is how Firefox's default high-contrast black mode on Windows 10 is interpreted. The default behaviour can be changed. You need to select the "Use system colours" option in the Language and Appearance settings.
In Windows 11, the set of contrasting themes has changed:
  • Aquatic.
  • Desert.
  • Dusk.
  • Night sky.
Section with podcast episodes from the Web Standards home page with system colours. White background became black, links and borders are purple, and plain text is white instead of dark grey.
"Web Standards" in Night Sky Mode in Vivaldi on Windows 11.
If the ready-made themes are not suitable, you can customise them yourself. This includes reducing the contrast.
Contrast
Users can separately increase or decrease the contrast level in the system without changing the screen brightness.
Who uses the setting:
  • People with visual impairments. For example, people with glaucoma.
  • People with migraines and headaches.
  • Users with old or poor-quality displays.
  • Other users who lack contrast levels due to lighting.
macOS and iOS have an Increased Contrast Mode. It increases the difference between shades of grey and makes the borders of elements clearer.
Settings affect the appearance of the system and web interfaces. Unlike system windows, only the contrast level is changed on websites. Of course, the borders of elements do not become clearer by themselves.
Comparing windows in normal mode and contrast-enhanced mode in macOS. In both windows, a picture of a screaming cat called «cute-cat.jpeg» is open. You can see controls for closing, expanding, zooming in and out, as well as additional settings.
In the high contrast mode, strangely enough, everything became more contrasty. Black frames appeared around the window and controls.
Transparency
Users can switch background transparency on or off. Opaque backgrounds are often chosen by those who want to increase contrast.
A transparent background can increase cognitive load and reduce the readability of text. Therefore, this setting is used by:
  • People with visual impairments. For example, with astigmatism or reduced vision.
  • Users with cognitive disabilities. For example, people with dyslexia or attention deficit disorder.
  • People with migraines and headaches.
Transparency is customisable on Windows and macOS.
These settings only affect transparency in the system interface.
Comparison of windows with and without transparency setting enabled in Windows. Both with system screen settings. The window has a navigation bar on the left and settings on the right.
This is how the transparency setting works in Windows 10. The navigation background of the first window is semi-transparent, and the second one is opaque and monochrome.
A word about media types
The @media directive has several media types. They describe the device on which the document is displayed.
  • all. All devices. It is set automatically if no other type is specified.
  • screen. Devices with screens. For example, phones and laptops.
  • print. Devices with preview and print functions. The same as 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. So far it is not supported by browsers. It used to be supported by Opera browser on Presto engine but stopped after switching to Blink.
In the future, it may be useful for special styles for screen readers. For example, to apply CSS properties for speech synthesis devices to necessary elements.
Media Features
And now let's move on to media features that help to make web interfaces more accessible.
Some of them don't have very impressive support yet. Something may change in the future with the development of CSS. In any case, it's good to know about them. You might even want to experiment with these media features in a small pet project now.
prefer-reduced-motion
Tracks whether animation settings are selected to reduce animation intensity.
There are two values:
  • no-preference, the default animation settings.
  • reduce, the modified animation settings.
Prefers-reduced-motion has good browser support at 91.75%.
It can be useful for any animation on the site. You can slow it down or disable it completely.
Setting animation: none to elements with animation will stop it completely.
@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 0a59f11..d0630ce 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-05-16T00:00:00.000Z"
-		}
 
How to avoid harming users with epilepsy and vestibular impairment
  • Usability
  • Design
  • Animation
  • CSS
 
Accessibility helps people not only to use interfaces without issues but also not to feel literally sick. People with epilepsy and vestibular impairment can struggle with this. In this article, I want to discuss what accessibility means for them.
Let's start by talking about vestibular impairments, epilepsy, and epileptic seizures.
Vestibular Disorders
Many people know the feeling of motion sickness, dizziness, and nausea. It could be happening to you because of poor sleep, a cold, and a bunch of other reasons.
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 disorders. It includes head injuries, vestibular migraine or migraine with aura, brain tumours and more. They often have similar symptoms:
  • dizziness;
  • nausea;
  • blurred vision;
  • headaches;
  • trouble concentrating.
And the trigger can be inaccessible interfaces. Facundo Corradini in an article on A List Apart described how he lay in bed for hours with severe vertigo after encounters with parallax.
There are indeed many such users. There are about 15% of the world's people with chronic migraines alone.
Epilepsy and seizures
Epileptic seizure is uncontrolled increased or synchronised activity of neurons in the brain. It results in seizures, paralysis, temporary failure of internal organs, loss or confusion, partial amnesia, and outbreaks of fear and anxiety.
Seizures can occur on their own or be part of entire illnesses. If they recur frequently, they are considered epilepsy.
Some statistics. About 8-10% of people in the world have had at least one epileptic seizure. In 3% they have resulted in epilepsy.
Seizures can be influenced not only by internal factors but also by external factors. For example, 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. We are most interested in photosensitive epilepsy (PSE). It is triggered by intense flickering light or movement. It occurs in 5% of all people with epilepsy. It occurs most often between the ages of 7 and 19.
So content that flashes, flickers and flashes can lead to an epileptic seizure. It seriously increases electrical activity in neurons.
What are the threats
So who can cause an epileptic seizure or other negative physical reaction?
  • Video.
  • Gifs.
  • Canvas.
  • SVG, CSS, and JS animations. For example, when there are moving images next to the text or the foreground and background are simultaneously scrolling in different directions - parallax effects.
  • Animated scrolling that lasts longer than 1/4 second.
  • Graphics with contrasting stripes, squares, spirals and concentric circles.
  • High contrast.
Not too long ago, I faced eye strain and feelings of nausea because of splash screen in WebStorm 2021.1 myself. It's just a static image though. Thanks to a JetBrains team for listening to the feedback and reduced the saturation of the images.
There are more examples of problematic interfaces in "Your Interactive Makes Me Sick" by Eileen Webb. I hope your vestibular system handles this challenge better than mine.
You don't even need an image or video to cause harm. A
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.
Tips & Tricks
It is dangerous to involve people with epilepsy and vestibular impairment in testing. So the only thing left to do is to be proactive and take into account the advice given by experts.
So what can we do to avoid harming users?
 The frequency of normal and red flashes is no more than 3 times per second (3 Hz). This is the minimum accessibility requirement for people with epileptic seizures.
A general flash is a pair of opposite states of relative brightness when it changes by 10% or more. In this case, the relative brightness of the dark image is less than 0.8. And red flash is a pair of opposite transitions where there is a saturated red colour in between.
You can check video and animations with the free software Photosensitive Epilepsy Analysis Tool (PEAT). However, it is only suitable for non-commercial purposes. For commercial purposes, there is a paid Harding Test.
 If the frequency of flashes is more than 3 times per second, you can reduce their area and make it a "Small safe area". This is less than 10% of the centre of the field of view or less than 25% of the screen size. This is because the central part of the eye consists of a large number of sensors. They are more active than others in transmitting signals to the visual cortex and can overload neurons.
This isn't the most reliable solution. A user could visit the site from a mobile device and bring it too close to their eyes.
 If possible, it's best to avoid red flashes or saturated shades of red in videos and animations altogether.
 Watch the contrast of the animation and do not make it too high.
 You can switch off the animation if it's not a key functionality. The prefers-reduced-motion media feature comes in handy for this.
It checks a selection of "Reduce Motion" on macOS or "Show animations" on Windows. Right now its global support is 96.75%. There's an example of how it works in the W3C demo.
There're no ironclad values for speed, smoothness and other animation properties. So you can use the experience of other developers or ask users about their experience.
Option 1 with prefers-reduced-motion only:
@media (prefers-reduced-motion: reduce) {
+		}
 
How to avoid harming users with epilepsy and vestibular impairment
  • Usability
  • Design
  • Animation
  • CSS
 
Accessibility helps people not only to use interfaces without issues but also not to feel literally sick. People with epilepsy and vestibular impairment can struggle with this. In this article, I want to discuss what accessibility means for them.
Let's start by talking about vestibular impairments, epilepsy, and epileptic seizures.
Vestibular Disorders
Many people know the feeling of motion sickness, dizziness, and nausea. It could be happening to you because of poor sleep, a cold, and a bunch of other reasons.
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 disorders. It includes head injuries, vestibular migraine or migraine with aura, brain tumours and more. They often have similar symptoms:
  • dizziness;
  • nausea;
  • blurred vision;
  • headaches;
  • trouble concentrating.
And the trigger can be inaccessible interfaces. Facundo Corradini in an article on A List Apart described how he lay in bed for hours with severe vertigo after encounters with parallax.
There are indeed many such users. There are about 15% of the world's people with chronic migraines alone.
Epilepsy and seizures
Epileptic seizure is uncontrolled increased or synchronised activity of neurons in the brain. It results in seizures, paralysis, temporary failure of internal organs, loss or confusion, partial amnesia, and outbreaks of fear and anxiety.
Seizures can occur on their own or be part of entire illnesses. If they recur frequently, they are considered epilepsy.
Some statistics. About 8-10% of people in the world have had at least one epileptic seizure. In 3% they have resulted in epilepsy.
Seizures can be influenced not only by internal factors but also by external factors. For example, 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. We are most interested in photosensitive epilepsy (PSE). It is triggered by intense flickering light or movement. It occurs in 5% of all people with epilepsy. It occurs most often between the ages of 7 and 19.
So content that flashes, flickers and flashes can lead to an epileptic seizure. It seriously increases electrical activity in neurons.
What are the threats
So who can cause an epileptic seizure or other negative physical reaction?
  • Video.
  • Gifs.
  • Canvas.
  • SVG, CSS, and JS animations. For example, when there are moving images next to the text or the foreground and background are simultaneously scrolling in different directions - parallax effects.
  • Animated scrolling that lasts longer than 1/4 second.
  • Graphics with contrasting stripes, squares, spirals and concentric circles.
  • High contrast.
Not too long ago, I faced eye strain and feelings of nausea because of splash screen in WebStorm 2021.1 myself. It's just a static image though. Thanks to a JetBrains team for listening to the feedback and reduced the saturation of the images.
There are more examples of problematic interfaces in "Your Interactive Makes Me Sick" by Eileen Webb. I hope your vestibular system handles this challenge better than mine.
You don't even need an image or video to cause harm. A
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.
Tips & Tricks
It is dangerous to involve people with epilepsy and vestibular impairment in testing. So the only thing left to do is to be proactive and take into account the advice given by experts.
So what can we do to avoid harming users?
 The frequency of normal and red flashes is no more than 3 times per second (3 Hz). This is the minimum accessibility requirement for people with epileptic seizures.
A general flash is a pair of opposite states of relative brightness when it changes by 10% or more. In this case, the relative brightness of the dark image is less than 0.8. And red flash is a pair of opposite transitions where there is a saturated red colour in between.
You can check video and animations with the free software Photosensitive Epilepsy Analysis Tool (PEAT). However, it is only suitable for non-commercial purposes. For commercial purposes, there is a paid Harding Test.
 If the frequency of flashes is more than 3 times per second, you can reduce their area and make it a "Small safe area". This is less than 10% of the centre of the field of view or less than 25% of the screen size. This is because the central part of the eye consists of a large number of sensors. They are more active than others in transmitting signals to the visual cortex and can overload neurons.
This isn't the most reliable solution. A user could visit the site from a mobile device and bring it too close to their eyes.
 If possible, it's best to avoid red flashes or saturated shades of red in videos and animations altogether.
 Watch the contrast of the animation and do not make it too high.
 You can switch off the animation if it's not a key functionality. The prefers-reduced-motion media feature comes in handy for this.
It checks a selection of "Reduce Motion" on macOS or "Show animations" on Windows. Right now its global support is 96.75%. There's an example of how it works in the W3C demo.
There're no ironclad values for speed, smoothness and other animation properties. So you can use the experience of other developers or ask users about their experience.
Option 1 with prefers-reduced-motion only:
@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 77f0e26..f899bd5 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
 
Everything you need to know about ARIA Live Regions
If you have a dynamically changing part of a page and you're thinking about making it accessible, there may be a legitimate question about how to do it. In the past, assistive technologies (including screen readers) didn't know how to handle them properly. Now the problem of accessibility of dynamically changing page content can be solved with ARIA.
  • HTML
  • Screen readers
 
CSS media feature to improve accessibility
What custom settings come and how to take them into account in web interfaces. You will learn about media features that track animation settings, contrast, transparency, inversion, colour scheme and forced colour mode.
  • 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
 
Everything you need to know about ARIA Live Regions
If you have a dynamically changing part of a page and you're thinking about making it accessible, there may be a legitimate question about how to do it. In the past, assistive technologies (including screen readers) didn't know how to handle them properly. Now the problem of accessibility of dynamically changing page content can be solved with ARIA.
  • HTML
  • Screen readers
 
CSS media feature to improve accessibility
What custom settings come and how to take them into account in web interfaces. You will learn about media features that track animation settings, contrast, transparency, inversion, colour scheme and forced colour mode.
  • 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 35273a4..9b34c34 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/index.html b/en/index.html
index 611cf2c..459d356 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
 
Everything you need to know about ARIA Live Regions
If you have a dynamically changing part of a page and you're thinking about making it accessible, there may be a legitimate question about how to do it. In the past, assistive technologies (including screen readers) didn't know how to handle them properly. Now the problem of accessibility of dynamically changing page content can be solved with 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
 
Everything you need to know about ARIA Live Regions
If you have a dynamically changing part of a page and you're thinking about making it accessible, there may be a legitimate question about how to do it. In the past, assistive technologies (including screen readers) didn't know how to handle them properly. Now the problem of accessibility of dynamically changing page content can be solved with 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/ru/404/index.html b/ru/404/index.html
index aa9fbb9..bdb64c8 100644
--- a/ru/404/index.html
+++ b/ru/404/index.html
@@ -1 +1 @@
-Page not found — Блог о цифровой доступности
 
Page not found
Most likely, such a page does not exist.
Go back to the main page
 Татьяна Фокина, 2021–2024
Разработано на 11ty, иконки с Lucide Нашли ошибку? Поделитесь ей на GitHub

\ No newline at end of file
+Page not found — Блог о цифровой доступности
 
Page not found
Most likely, such a page does not exist.
Go back to the main page
 Татьяна Фокина, 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 48a97a5..251384e 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-03T00:00:00.000Z"
-		}
 
role с несколькими значениями
  • ARIA
  • HTML
 
 Обновлено: 
Недавно случайно узнала, что 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
  • HTML
 
 Обновлено: 
Недавно случайно узнала, что 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 ba4385d..40a0a1c 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": "2021-11-01T00: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 на Windows 10.
Раздел с подкастами с главной страницы «Веб-стандарты» с системными цветами. Белый фон остался того же цвета, ссылки и границы теперь ярко-синие, а обычный текст чёрный вместо тёмно-серого.
Так своеобразно интерпретирует по умолчанию чёрный режим высокой контрастности Firefox на Windows 10. Поведение по умолчанию можно изменить. Нужно выбрать в настройках языка и внешнего вида (Language and Appearence) опцию «Использовать системные цвета» (Use system colors).
В Windows 11 набор контрастных тем изменился:
  • Водная (Aquatic).
  • Пустыня (Desert).
  • Сумерки (Dusk).
  • Ночное небо (Night sky).
Раздел с подкастами с главной страницы «Веб-стандарты» с системными цветами. Белый фон стал чёрным, ссылки и границы фиолетовые, а обычный текст белый вместо тёмно-серого.
«Веб-стандарты» в режиме ночного неба в Vivaldi на Windows 11.
Если не подходят готовые темы, то можно настроить их самостоятельно. В том числе уменьшить контрастность.
Контрастность
Пользователи могут отдельно повысить или понизить уровень контрастности в системе без изменения яркости экрана.
Кто пользуется настройкой:
  • Люди с особенностями зрения. Например, с глаукомой.
  • Люди с мигренями и головными болями.
  • Пользователи со старыми или некачественными дисплеями.
  • Другие пользователи, которым не хватает уровня контрастности из-за освещения.
В macOS и iOS есть режим повышенной контрастности (Increased Contrast Mode). Он увеличивает разницу между оттенками серого и делает границы элементов чётче.
Настройки влияют на внешний вид системы и веб-интерфейсов. В отличие от системных окон, на сайтах изменяется только уровень контрастности. Границы элементов, конечно, чётче сами по себе не становятся.
Сравнение окон в обычном режиме и в режиме повышенной контрастности в macOS. В обоих окнах открыта картинка с кричащим котом, которая называется «cute-cat.jpeg». Видны элементы управления для закрытия, разворачивания, увеличения и уменьшения, а ещё дополнительные настройки.
В режиме повышенной контрастности, как ни странно, всё стало более контрастным. Вокруг окна и элементов управления появились чёрные рамки.
Прозрачность
Пользователи могут включить или выключить прозрачность фона (transparency). Непрозрачный фон часто выбирают те, кто повышает контрастность.
Прозрачный фон может увеличить когнитивную нагрузку и уменьшить читаемость текста. Поэтому этой настройкой пользуются:
  • Люди с особенностями зрения. Например, с астигматизмом или сниженным зрением.
  • Пользователи с когнитивными особенностями. К примеру, люди с дислексией или синдром дефицита внимания.
  • Люди с мигренями и головными болями.
Прозрачность настраивается в Windows и macOS.
Эти настройки влияют только на прозрачность в интерфейсе системе.
Сравнение окон с включённой настройкой прозрачности и без неё в Windows. Оба с системными настройками экрана. В окне слева расположена панель навигации, справа — настройки.
Так работает настройка прозрачности в Windows 10. Фон навигации первого окна полупрозрачный, второй непрозрачный и однотонный.
Пара слов про медиатипы
У директивы @media есть несколько медиатипов. Они описывают устройство, на котором отображается документ.
  • all. Все устройства. Задаётся автоматически, если не указать другой тип.
  • screen. Устройства с экранами. Например, телефоны и ноутбуки.
  • print. Устройства с предварительным предпросмотром и функциями печати. Те же принтеры.
  • speech. Устройства с синтезом речи. К примеру, скринридеры и голосовые помощники.
Медиатип speech может быть интересен с точки зрения доступности. Пока что он не поддерживается браузерами. Раньше поддерживался браузером Opera на движке Presto, но перестал после перехода на Blink.
В будущем может пригодиться для специальных стилей для скринридеров. Например, чтобы применить к нужным элементам CSS-свойства для устройств с синтезом речи.
Медиафичи
А вот теперь переходим к медиафичам, которые помогут сделать веб-интерфейсы доступнее.
У части из них пока не очень впечатляющая поддержка. Что-то может измениться в будущем с развитием CSS. В любом случае про них полезно знать. Может даже захочется поэкспериментировать с этими медиафичами в небольшом пет-проекте уже сейчас.
prefers-reduced-motion
Отслеживает, выбраны ли настройки анимации для уменьшения её интенсивности.
Есть два значения:
  • no-preference, настройки анимации по умолчанию.
  • reduce, изменённые настройки анимации.
У prefers-reduced-motion хорошая поддержка браузерам — 91.75 %.
Она может пригодиться для любой анимации на сайте. Можно её замедлить или полностью отключить.
Если задать элементам с анимацией 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 на Windows 10.
Раздел с подкастами с главной страницы «Веб-стандарты» с системными цветами. Белый фон остался того же цвета, ссылки и границы теперь ярко-синие, а обычный текст чёрный вместо тёмно-серого.
Так своеобразно интерпретирует по умолчанию чёрный режим высокой контрастности Firefox на Windows 10. Поведение по умолчанию можно изменить. Нужно выбрать в настройках языка и внешнего вида (Language and Appearence) опцию «Использовать системные цвета» (Use system colors).
В Windows 11 набор контрастных тем изменился:
  • Водная (Aquatic).
  • Пустыня (Desert).
  • Сумерки (Dusk).
  • Ночное небо (Night sky).
Раздел с подкастами с главной страницы «Веб-стандарты» с системными цветами. Белый фон стал чёрным, ссылки и границы фиолетовые, а обычный текст белый вместо тёмно-серого.
«Веб-стандарты» в режиме ночного неба в Vivaldi на Windows 11.
Если не подходят готовые темы, то можно настроить их самостоятельно. В том числе уменьшить контрастность.
Контрастность
Пользователи могут отдельно повысить или понизить уровень контрастности в системе без изменения яркости экрана.
Кто пользуется настройкой:
  • Люди с особенностями зрения. Например, с глаукомой.
  • Люди с мигренями и головными болями.
  • Пользователи со старыми или некачественными дисплеями.
  • Другие пользователи, которым не хватает уровня контрастности из-за освещения.
В macOS и iOS есть режим повышенной контрастности (Increased Contrast Mode). Он увеличивает разницу между оттенками серого и делает границы элементов чётче.
Настройки влияют на внешний вид системы и веб-интерфейсов. В отличие от системных окон, на сайтах изменяется только уровень контрастности. Границы элементов, конечно, чётче сами по себе не становятся.
Сравнение окон в обычном режиме и в режиме повышенной контрастности в macOS. В обоих окнах открыта картинка с кричащим котом, которая называется «cute-cat.jpeg». Видны элементы управления для закрытия, разворачивания, увеличения и уменьшения, а ещё дополнительные настройки.
В режиме повышенной контрастности, как ни странно, всё стало более контрастным. Вокруг окна и элементов управления появились чёрные рамки.
Прозрачность
Пользователи могут включить или выключить прозрачность фона (transparency). Непрозрачный фон часто выбирают те, кто повышает контрастность.
Прозрачный фон может увеличить когнитивную нагрузку и уменьшить читаемость текста. Поэтому этой настройкой пользуются:
  • Люди с особенностями зрения. Например, с астигматизмом или сниженным зрением.
  • Пользователи с когнитивными особенностями. К примеру, люди с дислексией или синдром дефицита внимания.
  • Люди с мигренями и головными болями.
Прозрачность настраивается в Windows и macOS.
Эти настройки влияют только на прозрачность в интерфейсе системе.
Сравнение окон с включённой настройкой прозрачности и без неё в Windows. Оба с системными настройками экрана. В окне слева расположена панель навигации, справа — настройки.
Так работает настройка прозрачности в Windows 10. Фон навигации первого окна полупрозрачный, второй непрозрачный и однотонный.
Пара слов про медиатипы
У директивы @media есть несколько медиатипов. Они описывают устройство, на котором отображается документ.
  • all. Все устройства. Задаётся автоматически, если не указать другой тип.
  • screen. Устройства с экранами. Например, телефоны и ноутбуки.
  • print. Устройства с предварительным предпросмотром и функциями печати. Те же принтеры.
  • speech. Устройства с синтезом речи. К примеру, скринридеры и голосовые помощники.
Медиатип speech может быть интересен с точки зрения доступности. Пока что он не поддерживается браузерами. Раньше поддерживался браузером Opera на движке Presto, но перестал после перехода на Blink.
В будущем может пригодиться для специальных стилей для скринридеров. Например, чтобы применить к нужным элементам CSS-свойства для устройств с синтезом речи.
Медиафичи
А вот теперь переходим к медиафичам, которые помогут сделать веб-интерфейсы доступнее.
У части из них пока не очень впечатляющая поддержка. Что-то может измениться в будущем с развитием CSS. В любом случае про них полезно знать. Может даже захочется поэкспериментировать с этими медиафичами в небольшом пет-проекте уже сейчас.
prefers-reduced-motion
Отслеживает, выбраны ли настройки анимации для уменьшения её интенсивности.
Есть два значения:
  • no-preference, настройки анимации по умолчанию.
  • reduce, изменённые настройки анимации.
У prefers-reduced-motion хорошая поддержка браузерам — 91.75 %.
Она может пригодиться для любой анимации на сайте. Можно её замедлить или полностью отключить.
Если задать элементам с анимацией 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 8aee3d6..7f43442 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": "2021-07-19T00:00:00.000Z"
-		}
 
Как не навредить пользователям с эпилепсией и вестибулярными нарушениями
  • Юзабилити
  • Дизайн
  • Анимация
  • CSS
 
Доступность помогает людям не только без проблем пользоваться интерфейсами, но и не чувствовать себя буквально плохо. С этим могут столкнуться люди с эпилепсией и вестибулярными нарушениями. В сегодняшнем посте хочу обсудить, что значит доступность для них.
Давайте для начала поговорим про вестибулярные нарушения, эпилепсию и эпилептические приступы.
Вестибулярные нарушения
Многие знают, что такое укачивание, головокружение и чувство тошноты. Это могло произойти с вами из-за плохого сна, простуды и кучи других причин.
Вестибулярные нарушения (Vestibular Disorders) связаны с внутренним ухом и частью головного мозга, которая контролирует баланс и движение глаз.
Это большая группа нарушений. В неё входят травмы головы, вестибулярная мигрень или мигрень с аурой, опухоли мозга и многое другое. Они часто имеют похожие симптомы:
  • головокружение;
  • тошнота;
  • размытое зрение;
  • головные боли;
  • проблемы с концентрацией внимания.
И триггером могут стать недоступные интерфейсы. Факундо Коррадини в статье на A List Apart рассказывал как часами лежал в кровати с сильным головокружением после встреч с параллаксом.
Таких пользователей действительно много. Одних только людей с хроническими мигренями в мире живёт около 15 %.
Эпилепсия и приступы
Эпилептический приступ (Seizure) – неконтролируемая повышенная или синхронная активность нейронов в головном мозге. Она приводит к судорогам, параличу, временному сбою внутренних органов, потере или спутанности сознания, частичной амнезии, вспышкам страха и тревожности.
Приступы могут случаться самостоятельно или быть частью целых заболеваний. Если они часто повторяются, то это считается эпилепсией.
Немного статистики. Примерно у 8–10 % людей в мире происходил минимум один эпилептический приступ. У 3 % они привели к эпилепсии.
На возникновение приступов могут влиять не только внутренние, но и внешние факторы. Например, свет или звуки.
Приступы, спровоцированные светом, звуками и даже чтением называются рефлекторными. Когда таких приступов много, то у человека рефлекторная эпилепсия (Reflex Epilepsy, RE).
Рефлекторная эпилепсия бывает нескольких типов. Больше всего нас интересует светочувствительная (Photosensitive Epilepsy, PSE). Её провоцируют интенсивный мерцающий свет или движения. Она встречается у 5 % от всего количества людей с эпилепсией. Чаще всего такие приступы случаются в возрасте от 7 до 19 лет.
Так что контент, который мигает, мерцает и вспыхивает, может привести к эпилептическому приступу. Он серьёзно повышает электрическую активность в нейронах.
Какие бывают угрозы
Кто же может стать виновником эпилептического приступа или другой негативной физической реакции?
  • Видео.
  • Гифки.
  • Canvas.
  • SVG-, CSS- и JS-анимация. Например, когда рядом с текстом есть подвижные изображения или одновременно скроллятся в разных направлениях передний и задний планы — параллакс-эффекты.
  • Анимированная прокрутка, которая длится больше 1/4 секунды.
  • Графика с контрастными полосами, клетками, спиралями и концентрическими кругами.
  • Высокая контрастность.
Не так давно сама столкнулась с глазной болью и чувством тошноты из-за сплэшскрина в WebStorm 2021.1. Хотя это всего лишь статичная картинка. Спасибо команде JetBrains, которая прислушалась к отзывам и снизила насыщенность изображений.
Больше примеров проблемных интерфейсов есть в «Your Interactive Makes Me Sick» Эйлин Уэбб. Надеюсь, ваш вестибулярный аппарат справится с этим испытанием лучше, чем мой.
Вам даже не нужны видео или изображение, чтобы причинить кому-то вред. Простой <div>, который с помощью JavaScript быстро меняет цвет и яркость, тоже может навредить. И мигание можно встретить где угодно. К примеру, спиннеры, которые появляются во время загрузки страниц, могут вращаться и мигать одновременно.
MDN.
Советы и рекомендации
Людей с эпилепсией и вестибулярными нарушениями опасно привлекать к тестированию. Поэтому остаётся действовать превентивно и учитывать рекомендации, которые дают эксперты.
Так что мы можем сделать для того, чтобы не навредить пользователям?
 Частота обычных и красных вспышек — не больше 3 раз в секунду (3 Гц). Это минимальное требование по доступности для людей с эпилептическими приступами.
Обычная вспышка (General flash) — это пара противоположных состояний относительной яркости, когда она изменяется на 10 % или больше. При этом относительная яркость тёмного изображения меньше 0,8. А красная (Red flash) — пара противоположных переходов, между которыми есть насыщенный красный цвет.
Проверить видео и анимацию можно в бесплатной программе Photosensitive Epilepsy Analysis Tool (PEAT). Правда, она подходит только для некоммерческих целей. Для коммерческих есть платная Harding Test.
 Если частота вспышек больше 3 раз в секунду, то можно уменьшить их область и сделать её «безопасной маленькой областью» (Small safe area). Её размер — меньше 10 % центральной части поля зрения или меньше 25 % от размера экрана. Это связано с тем, что центральная часть глаза состоит из большого количества сенсоров. Они активнее других передают сигналы в зрительную кору и могут перегрузить нейроны.
Это не самое надёжное решение. Пользователь может зайти на сайт с мобильного устройства и поднести его слишком близко к глазам.
 По возможности лучше вообще избегать в видео и анимации красных вспышек или насыщенных оттенков красного.
 Следите за контрастностью анимации и не делайте её слишком высокой.
 Можно отключить анимацию, если она не ключевой функционал. Для этого пригодится медиафича prefers-reduced-motion.
Она проверяет выбор настроек «Уменьшить движение» (Reduce Motion) в macOS или «Показывать анимацию» (Show animations) в Windows. Сейчас её глобальная поддержка 91.75 %. Пример того, как это работает, есть в демке W3C.
Железобетонных значений для скорости, плавности и других свойств анимации нет. Так что можно воспользоваться опытом других разработчиков или спросить у пользователей про их опыт.
Вариант 1 только с prefers-reduced-motion:
@media (prefers-reduced-motion: reduce) {
+		}
 
Как не навредить пользователям с эпилепсией и вестибулярными нарушениями
  • Юзабилити
  • Дизайн
  • Анимация
  • CSS
 
Доступность помогает людям не только без проблем пользоваться интерфейсами, но и не чувствовать себя буквально плохо. С этим могут столкнуться люди с эпилепсией и вестибулярными нарушениями. В сегодняшнем посте хочу обсудить, что значит доступность для них.
Давайте для начала поговорим про вестибулярные нарушения, эпилепсию и эпилептические приступы.
Вестибулярные нарушения
Многие знают, что такое укачивание, головокружение и чувство тошноты. Это могло произойти с вами из-за плохого сна, простуды и кучи других причин.
Вестибулярные нарушения (Vestibular Disorders) связаны с внутренним ухом и частью головного мозга, которая контролирует баланс и движение глаз.
Это большая группа нарушений. В неё входят травмы головы, вестибулярная мигрень или мигрень с аурой, опухоли мозга и многое другое. Они часто имеют похожие симптомы:
  • головокружение;
  • тошнота;
  • размытое зрение;
  • головные боли;
  • проблемы с концентрацией внимания.
И триггером могут стать недоступные интерфейсы. Факундо Коррадини в статье на A List Apart рассказывал как часами лежал в кровати с сильным головокружением после встреч с параллаксом.
Таких пользователей действительно много. Одних только людей с хроническими мигренями в мире живёт около 15 %.
Эпилепсия и приступы
Эпилептический приступ (Seizure) – неконтролируемая повышенная или синхронная активность нейронов в головном мозге. Она приводит к судорогам, параличу, временному сбою внутренних органов, потере или спутанности сознания, частичной амнезии, вспышкам страха и тревожности.
Приступы могут случаться самостоятельно или быть частью целых заболеваний. Если они часто повторяются, то это считается эпилепсией.
Немного статистики. Примерно у 8–10 % людей в мире происходил минимум один эпилептический приступ. У 3 % они привели к эпилепсии.
На возникновение приступов могут влиять не только внутренние, но и внешние факторы. Например, свет или звуки.
Приступы, спровоцированные светом, звуками и даже чтением называются рефлекторными. Когда таких приступов много, то у человека рефлекторная эпилепсия (Reflex Epilepsy, RE).
Рефлекторная эпилепсия бывает нескольких типов. Больше всего нас интересует светочувствительная (Photosensitive Epilepsy, PSE). Её провоцируют интенсивный мерцающий свет или движения. Она встречается у 5 % от всего количества людей с эпилепсией. Чаще всего такие приступы случаются в возрасте от 7 до 19 лет.
Так что контент, который мигает, мерцает и вспыхивает, может привести к эпилептическому приступу. Он серьёзно повышает электрическую активность в нейронах.
Какие бывают угрозы
Кто же может стать виновником эпилептического приступа или другой негативной физической реакции?
  • Видео.
  • Гифки.
  • Canvas.
  • SVG-, CSS- и JS-анимация. Например, когда рядом с текстом есть подвижные изображения или одновременно скроллятся в разных направлениях передний и задний планы — параллакс-эффекты.
  • Анимированная прокрутка, которая длится больше 1/4 секунды.
  • Графика с контрастными полосами, клетками, спиралями и концентрическими кругами.
  • Высокая контрастность.
Не так давно сама столкнулась с глазной болью и чувством тошноты из-за сплэшскрина в WebStorm 2021.1. Хотя это всего лишь статичная картинка. Спасибо команде JetBrains, которая прислушалась к отзывам и снизила насыщенность изображений.
Больше примеров проблемных интерфейсов есть в «Your Interactive Makes Me Sick» Эйлин Уэбб. Надеюсь, ваш вестибулярный аппарат справится с этим испытанием лучше, чем мой.
Вам даже не нужны видео или изображение, чтобы причинить кому-то вред. Простой <div>, который с помощью JavaScript быстро меняет цвет и яркость, тоже может навредить. И мигание можно встретить где угодно. К примеру, спиннеры, которые появляются во время загрузки страниц, могут вращаться и мигать одновременно.
MDN.
Советы и рекомендации
Людей с эпилепсией и вестибулярными нарушениями опасно привлекать к тестированию. Поэтому остаётся действовать превентивно и учитывать рекомендации, которые дают эксперты.
Так что мы можем сделать для того, чтобы не навредить пользователям?
 Частота обычных и красных вспышек — не больше 3 раз в секунду (3 Гц). Это минимальное требование по доступности для людей с эпилептическими приступами.
Обычная вспышка (General flash) — это пара противоположных состояний относительной яркости, когда она изменяется на 10 % или больше. При этом относительная яркость тёмного изображения меньше 0,8. А красная (Red flash) — пара противоположных переходов, между которыми есть насыщенный красный цвет.
Проверить видео и анимацию можно в бесплатной программе Photosensitive Epilepsy Analysis Tool (PEAT). Правда, она подходит только для некоммерческих целей. Для коммерческих есть платная Harding Test.
 Если частота вспышек больше 3 раз в секунду, то можно уменьшить их область и сделать её «безопасной маленькой областью» (Small safe area). Её размер — меньше 10 % центральной части поля зрения или меньше 25 % от размера экрана. Это связано с тем, что центральная часть глаза состоит из большого количества сенсоров. Они активнее других передают сигналы в зрительную кору и могут перегрузить нейроны.
Это не самое надёжное решение. Пользователь может зайти на сайт с мобильного устройства и поднести его слишком близко к глазам.
 По возможности лучше вообще избегать в видео и анимации красных вспышек или насыщенных оттенков красного.
 Следите за контрастностью анимации и не делайте её слишком высокой.
 Можно отключить анимацию, если она не ключевой функционал. Для этого пригодится медиафича prefers-reduced-motion.
Она проверяет выбор настроек «Уменьшить движение» (Reduce Motion) в macOS или «Показывать анимацию» (Show animations) в Windows. Сейчас её глобальная поддержка 91.75 %. Пример того, как это работает, есть в демке 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 9c05473..91b25be 100644
--- a/ru/articles/index.html
+++ b/ru/articles/index.html
@@ -1 +1 @@
-Все статьи — Блог о цифровой доступности
 
Все статьи
Клавиатура
Разбираемся с критерием WCAG про доступность интерфейса для клавиатуры.
  • WCAG
  • Клавиатура
  • HTML
 
Внешний вид фокуса
Как должны выглядеть элементы при фокусе с клавиатуры по мнению WCAG 2.2.
  • WCAG
  • Дизайн
  • CSS
  • Клавиатура
 
Принципы WCAG. Видимый фокус
Разбираемся с критерием о видимом клавиатурном фокусе у интерактивных элементов.
  • WCAG
  • Дизайн
  • CSS
  • Клавиатура
 
role с несколькими значениями
Разберёмся с несколькими значениями для атрибута роли. В каких случаях это пригодится, и какие отношения с двумя ролями у браузеров и скринридеров.
  • ARIA
  • HTML
 
CSS-медиафичи для улучшения доступности
Какие пользовательские настройки бывают и как их учитывать в веб-интерфейсах. Узнаете про медиафичи, которые отслеживают настройки анимации, контрастности, прозрачности, инверсию, цветовую схему и режим принудительных цветов.
  • CSS
  • Юзабилити
 
Разбираемся со skip link
Как пропустить большую навигацию с помощью skip link, кому нужны такие ссылки и как их добавить на свой сайт.
  • Паттерны
  • HTML
  • CSS
 
Как не навредить пользователям с эпилепсией и вестибулярными нарушениями
Что, если пользователя укачивает из-за сайта? А вдруг у него случится эпилептический приступ? Давайте разберёмся с тем, какими должны быть интерфейсы для пользователей с эпилепсией и вестибулярными нарушениями.
  • Юзабилити
  • Дизайн
  • Анимация
  • CSS
 
 Татьяна Фокина, 2021–2024
Разработано на 11ty, иконки с Lucide Нашли ошибку? Поделитесь ей на GitHub

\ No newline at end of file
+Все статьи — Блог о цифровой доступности
 
Все статьи
Клавиатура
Разбираемся с критерием WCAG про доступность интерфейса для клавиатуры.
  • WCAG
  • Клавиатура
  • HTML
 
Внешний вид фокуса
Как должны выглядеть элементы при фокусе с клавиатуры по мнению WCAG 2.2.
  • WCAG
  • Дизайн
  • CSS
  • Клавиатура
 
Принципы WCAG. Видимый фокус
Разбираемся с критерием о видимом клавиатурном фокусе у интерактивных элементов.
  • WCAG
  • Дизайн
  • CSS
  • Клавиатура
 
role с несколькими значениями
Разберёмся с несколькими значениями для атрибута роли. В каких случаях это пригодится, и какие отношения с двумя ролями у браузеров и скринридеров.
  • ARIA
  • HTML
 
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 47baf7a..dd7cff9 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 c1a8beb..aff4614 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": "2022-11-14T00:00:00.000Z"
-		}
 
Принципы WCAG. Клавиша символа в клавиатурном сокращении
  • 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» («Режим команд») подходящую опцию.
На скриншоте выделена часть с клавиатурными сокращениями. Выбран чекбокс «Клавиши символов, под ним подсказка про то, что их можно отключить и взамен использовать команды с клавишами-модификаторами. Дальше заголовок «Палитра команд». Под заголовком подсказка про то, что можно изменить шорткаты и выбрать другие клавиши для работы в режиме поиска и в режиме команд. Рядом расположены два выпадающих списка. Один называется «Режим поиска», другой «Режим команд». Фокус сделан на списке с режимом команд, из него выпало меню с несколькими вариантами клавиш. Control shift k (по умолчанию), control k, control alt k, control p, control 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. Клавиша символа в клавиатурном сокращении
  • 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» («Режим команд») подходящую опцию.
На скриншоте выделена часть с клавиатурными сокращениями. Выбран чекбокс «Клавиши символов, под ним подсказка про то, что их можно отключить и взамен использовать команды с клавишами-модификаторами. Дальше заголовок «Палитра команд». Под заголовком подсказка про то, что можно изменить шорткаты и выбрать другие клавиши для работы в режиме поиска и в режиме команд. Рядом расположены два выпадающих списка. Один называется «Режим поиска», другой «Режим команд». Фокус сделан на списке с режимом команд, из него выпало меню с несколькими вариантами клавиш. Control shift k (по умолчанию), control k, control alt k, control p, control 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 d024d29..cabfb2b 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": "2022-10-22T00:00:00.000Z"
-		}
 
Принципы WCAG. Консистентная идентификация
  • WCAG
  • Дизайн
  • ARIA
  • HTML
 
В Руководстве по доступности веб-контента (Web Content Accessibility Guidelines или коротко WCAG) описаны барьеры, которые лучше избегать в цифровых продуктах.
Проблема WCAG в том, что не всегда понятно, что руководства хотят от дизайнеров, разработчиков и других специалистов. Так что решила написать серию постов с коротким разбором критериев простым языком.
Первый пост серии про критерий 3.2.4: Консистентная идентификация. Критерий входит в руководство про понятность и он уровня AA, поэтому точно столкнётесь с ним при аудите и тестировании.
Коротко о критерии
Элементы с одинаковой функциональностью выглядят и работают одинаково на разных страницах сайта.
Одинаковая функциональность означает, что элементы делают одно и то же. К примеру, открывают одно диалоговое окно или ведут на одну страницу.
Хотя критерий об элементах на разных страницах, хорошо следить и за консистентностью на одной странице.
Подробнее
Критерий касается интерактивных элементов, к примеру, кнопок, ссылок, вкладок и подобного. У консистентных элементов примерно одинаковые:
  • названия — которые видно визуально или только вспомогательным технологиям;
  • функции — как один и тот же элемент работает на разных страницах;
  • внешний вид — иконки, стили и прочее.
Названия элементов не обязательно должны быть одинаковыми и могут немного отличаться. Ничего страшного, если одна кнопка называется «Перейти к следующему слайду», а у другая — «Перейти к слайду 2». Другой пример — две ссылки с немного разным текстом, которые ведут на одну и ту же страницу. Это тоже не нарушает критерий.
Кому это важно
  • Все пользователи, которые ищут элементы с одинаковой функциональностью на разных страницах сайтов. Например, ссылку на личный кабинет.
  • Пользователи с когнитивными особенностями — с дислексией, синдромом дефицита внимания и другими нейроотличиями.
  • Люди, которым нужны текстовые альтернативы, — названия кнопок и ссылок, описания изображений. Это любые пользователи вспомогательных технологий, особенно пользователи скринридеров и голосового управления.
Кнопки и ссылки, которые делают одно и то же, но называются по-разному, могут привести к когнитивной перегрузке. Это барьер для людей с небольшими когнитивными ресурсами.
Когнитивная перегрузка — теория о том, как внешние и внутренние факторы влияют на рабочую или оперативную память человека. В оперативной памяти временно хранится важная информаций для решения разных задач.
Кнопка для входа в личный кабинет, которая выглядит по-разному, но ведёт себя одинаково на главной и других страницах, увеличивает внешнюю нагрузку на рабочую память. Это может вызвать стресс, раздражение, фрустрацию и заставить кого-то уйти с сайта из-за когнитивной перегрузки.
Как избежать барьер
Часто проблемы с консистентностью появляются ещё на этапе дизайна. С этим помогает справиться атомарный дизайн и продуманная дизайн-система. На уровне кода следить за консистентностью тоже легче, когда есть дизайн-система и используется компонентный подход.
Примеры соответствия критерию
  • Кнопки с одинаковой иконкой лупы и называнием «Поиск по сайту».
  • Элементы с разными функциями, но с одинаковыми иконками в виде галочки и c разными видимыми названиями «Согласен» и «Получать рассылку».
  • Пагинация со ссылками, в названиях которых есть номера страниц. Например, «Страница 1», «Страница 2», «Страница 3».
На сайте gov.uk есть поиск с кнопкой с иконкой лупы на отдельных страницах и в меню. Иконки и сами кнопки выглядят одинаково, у них везде одно и то же название «Search GOV.UK».
Главная страница сайта правительства Британии. Под заголовком с приветствием пользователей две колонки с содержимым. В одной ссылки на популярные страницы, в другой строка поиска по сайту. У строки видимая подпись «Искать gov.uk», рядом со строкой кнопка с иконкой лупы.
На главной странице gov.uk есть поле поиска с кнопкой со скрытой подписью «Search GOV.UK».
Другая страница сайта правительства Британии с информацией о входе в аккаунт на сайте. Открыто меню с пустой строкой поиска по сайту. У неё есть видимая подпись «Искать gov.uk», рядом со строкой расположена кнопка с иконкой лупы.
На другой странице gov.uk есть поле поиска из меню с кнопкой с такой же скрытой подписью «Search GOV.UK».
На сайте Amazon на страницах с категориями товаров есть пагинация. В ней одинаковые по функциональности элементы с одинаковыми названиями в aria-label — «Current page, page 1», «Current page, page 2» и так далее.
На странице расположено несколько карточек товаров, выделена пагинация. Видны элементы со стрелками «Вперёд», «Назад» и номерами «1», «2», «3», «400» и многоточием между «3» и «400». Сейчас активна первая страница.
Страница с товарами для животных на Amazon. На ней есть пагинация с кнопками с видимыми названиями «Previous» и «Next», а также ссылки на конкретные страницы со скрытыми названиями «Current page, page 1» и так далее.
На странице расположено несколько карточек товаров и блок с ответами на самые частые вопросы, выделена пагинация. Видны элементы со стрелками «Вперёд», «Назад» и номерами «1», «2», «3», «7» и многоточием между «3» и «7». Сейчас активна первая страница.
Другая страница Amazon с пагинацией. У всех ссылок такие же видимые и скрытые подписи, как и на других страницах сайта.
Примеры барьеров
  • Кнопки с одинаковой иконкой лупы для поиска по сайту, но с разными названиями «Поиск» («Search») и «Найти» («Find»).
  • Ссылки с иконкой в виде дома, которые ведут на главную страницу, но у них разные скрытые названия в aria-label — «Главная» и «Перейти к основной странице сайта».
Как тестировать
Проверить консистентность интерактивных элементов поможет ручное и пользовательское тестирование. Примерные шаги:
  • Сравните элементы с одинаковой функциональностью на разных страницах и убедитесь, что у них одинаковые названия и они не сильно отличаются друг от друга визуально.
  • Проведите тестирование с пользователями, чтобы найти элементы с одинаковой функциональностью, которые вызывают трудности.
Что почитать
Другие статьи
 Татьяна Фокина, 2021–2024
Разработано на 11ty, иконки с Lucide Нашли ошибку? Поделитесь ей на GitHub

\ No newline at end of file
+		}
 
Принципы WCAG. Консистентная идентификация
  • WCAG
  • Дизайн
  • ARIA
  • HTML
 
В Руководстве по доступности веб-контента (Web Content Accessibility Guidelines или коротко WCAG) описаны барьеры, которые лучше избегать в цифровых продуктах.
Проблема WCAG в том, что не всегда понятно, что руководства хотят от дизайнеров, разработчиков и других специалистов. Так что решила написать серию постов с коротким разбором критериев простым языком.
Первый пост серии про критерий 3.2.4: Консистентная идентификация. Критерий входит в руководство про понятность и он уровня AA, поэтому точно столкнётесь с ним при аудите и тестировании.
Коротко о критерии
Элементы с одинаковой функциональностью выглядят и работают одинаково на разных страницах сайта.
Одинаковая функциональность означает, что элементы делают одно и то же. К примеру, открывают одно диалоговое окно или ведут на одну страницу.
Хотя критерий об элементах на разных страницах, хорошо следить и за консистентностью на одной странице.
Подробнее
Критерий касается интерактивных элементов, к примеру, кнопок, ссылок, вкладок и подобного. У консистентных элементов примерно одинаковые:
  • названия — которые видно визуально или только вспомогательным технологиям;
  • функции — как один и тот же элемент работает на разных страницах;
  • внешний вид — иконки, стили и прочее.
Названия элементов не обязательно должны быть одинаковыми и могут немного отличаться. Ничего страшного, если одна кнопка называется «Перейти к следующему слайду», а у другая — «Перейти к слайду 2». Другой пример — две ссылки с немного разным текстом, которые ведут на одну и ту же страницу. Это тоже не нарушает критерий.
Кому это важно
  • Все пользователи, которые ищут элементы с одинаковой функциональностью на разных страницах сайтов. Например, ссылку на личный кабинет.
  • Пользователи с когнитивными особенностями — с дислексией, синдромом дефицита внимания и другими нейроотличиями.
  • Люди, которым нужны текстовые альтернативы, — названия кнопок и ссылок, описания изображений. Это любые пользователи вспомогательных технологий, особенно пользователи скринридеров и голосового управления.
Кнопки и ссылки, которые делают одно и то же, но называются по-разному, могут привести к когнитивной перегрузке. Это барьер для людей с небольшими когнитивными ресурсами.
Когнитивная перегрузка — теория о том, как внешние и внутренние факторы влияют на рабочую или оперативную память человека. В оперативной памяти временно хранится важная информаций для решения разных задач.
Кнопка для входа в личный кабинет, которая выглядит по-разному, но ведёт себя одинаково на главной и других страницах, увеличивает внешнюю нагрузку на рабочую память. Это может вызвать стресс, раздражение, фрустрацию и заставить кого-то уйти с сайта из-за когнитивной перегрузки.
Как избежать барьер
Часто проблемы с консистентностью появляются ещё на этапе дизайна. С этим помогает справиться атомарный дизайн и продуманная дизайн-система. На уровне кода следить за консистентностью тоже легче, когда есть дизайн-система и используется компонентный подход.
Примеры соответствия критерию
  • Кнопки с одинаковой иконкой лупы и называнием «Поиск по сайту».
  • Элементы с разными функциями, но с одинаковыми иконками в виде галочки и c разными видимыми названиями «Согласен» и «Получать рассылку».
  • Пагинация со ссылками, в названиях которых есть номера страниц. Например, «Страница 1», «Страница 2», «Страница 3».
На сайте gov.uk есть поиск с кнопкой с иконкой лупы на отдельных страницах и в меню. Иконки и сами кнопки выглядят одинаково, у них везде одно и то же название «Search GOV.UK».
Главная страница сайта правительства Британии. Под заголовком с приветствием пользователей две колонки с содержимым. В одной ссылки на популярные страницы, в другой строка поиска по сайту. У строки видимая подпись «Искать gov.uk», рядом со строкой кнопка с иконкой лупы.
На главной странице gov.uk есть поле поиска с кнопкой со скрытой подписью «Search GOV.UK».
Другая страница сайта правительства Британии с информацией о входе в аккаунт на сайте. Открыто меню с пустой строкой поиска по сайту. У неё есть видимая подпись «Искать gov.uk», рядом со строкой расположена кнопка с иконкой лупы.
На другой странице gov.uk есть поле поиска из меню с кнопкой с такой же скрытой подписью «Search GOV.UK».
На сайте Amazon на страницах с категориями товаров есть пагинация. В ней одинаковые по функциональности элементы с одинаковыми названиями в aria-label — «Current page, page 1», «Current page, page 2» и так далее.
На странице расположено несколько карточек товаров, выделена пагинация. Видны элементы со стрелками «Вперёд», «Назад» и номерами «1», «2», «3», «400» и многоточием между «3» и «400». Сейчас активна первая страница.
Страница с товарами для животных на Amazon. На ней есть пагинация с кнопками с видимыми названиями «Previous» и «Next», а также ссылки на конкретные страницы со скрытыми названиями «Current page, page 1» и так далее.
На странице расположено несколько карточек товаров и блок с ответами на самые частые вопросы, выделена пагинация. Видны элементы со стрелками «Вперёд», «Назад» и номерами «1», «2», «3», «7» и многоточием между «3» и «7». Сейчас активна первая страница.
Другая страница 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 f1473a8..2fee23c 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": "2023-01-27T00:00:00.000Z"
-		}
 
Внешний вид фокуса
  • WCAG
  • Дизайн
  • CSS
  • Клавиатура
 
В этом посте из серии про разбор Руководств по доступности веб-контента (Web Content Accessibility Guidelines, коротко WCAG) расскажу про новый критерий из WCAG 2.2 — 2.4.11: внешний вид фокуса. Он связан с другим критерием про видимый фокус, про который уже рассказывала раньше.
Критерий про внешний вид фокуса уровня AA. Он относится к принципу управляемости и к руководству про доступность с клавиатуры.
В первоначальной версии черновика WCAG 2.2 было два критерия про то, как должен выглядеть фокус. Один минимальный уровня AA, другой продвинутый уровня AAA. В итоге от продвинутого отказались и оставили только минимальный.
Это один из самых сложных критериев, которые планируют добавить в новую версию WCAG. Сейчас он активно обсуждается и дорабатывается.
Коротко
Когда элемент интерфейса получает фокус с клавиатуры, индикатор фокуса должен:
  • обводить элемент;
  • иметь соотношение контраста минимум 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, а вот для градиентной тени это не важно.
Несколько вариантов кнопок без фокуса и в фокусе. Одна кнопка без фокуса с чёрным фоном, белым текстом «Настройки» и прямыми углами. При фокусе она становится больше, внутри появляется белая жирная рамка, меняется цвет фона на белый, рядом с названием появляется жирная белая вертикальная черта и не такая жирная горизонтальная. Другая кнопка без фокуса с серым фоном, таким же названием и со скруглёнными краями. При фокусе у неё появляется чёрная сплошная и пунктирная рамки снаружи, а ещё размытая серая тень. Последняя кнопка круглая и с иконкой лупы внутри. При фокусе у неё появляется жирная круглая рамка внутри, более тонкая рамка снаружи и двойная рамка со светло-фиолетовой линией внутри и чёрной снаружи.
Варианты стилей фокуса, которые соответствуют критерию 2.4.11.
Если в элемент вложено несколько интерактивных, критерий про внешний вид фокуса распространяется в первую очередь на дочерние элементы. Например, как в кастомном комбинированном списке или в панели вкладок. При этом в случае таких сложных интерактивных элементов фокус может быть:
  • у всего компонента;
  • у вложенных в него компонентов;
  • одновременно у всего компонента и у вложенных в него элементов.
Для ссылок не критично, если индикатор фокуса не сплошной и одна из его сторон скрывается при переносе ссылки. Обычно это происходит, когда используете свойство 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 пикселя. Кнопки с розовым фоном при фокусе меняют свой фон на белый, они обводятся розовой рамкой, а снаружи появляется ещё одна рамка толщиной 3 пикселя.
Несколько видов элементов в состоянии фокуса и без — ссылки и несколько кнопок. Они подробно описаны до картинки.
Стили фокуса у ссылок и кнопок на сайте Fable.
На gov.uk также используют несколько вариантов стилей для фокуса.
Ссылки по умолчанию синие с тонкой чертой такого же цвета под ними. Когда делаете на них фокус, они становятся чёрными, нижнее подчёркивание тоже становится чёрным и более жирным, а фон меняется на жёлтый.
Что касается текстовых полей, по умолчанию вокруг них тонкая чёрная рамка. При фокусе рамка становится более жирной, дополнительно вокруг неё появляется ещё одна жёлтого цвета.
У некоторых кнопок при фокусе фон с серого меняется на жёлтый, а более жирная нижняя граница увеличивается где-то на 3 пикселя.
Несколько видов элементов в состоянии фокуса и без него — поле поиска, ссылки и кнопки. Подробнее описаны до картинки.
Стили кнопок, ссылок и полей на gov.uk.
Примеры барьеров
  • Вокруг названия вкладки при фокусе появляется пунктирная черта с точками, ширина которой 1 пиксель.
  • При фокусе внутри кнопки рядом с текстом появляется вертикальная черта толщиной 1 пиксель.
На сайте музея Ikea при фокусе на ссылках вокруг них появляется тонкая пунктирная рамка светло-серого цвета или тёмно-серого цвета в зависимости от цвета текста. Для неё используется свойство outline со значением 1px dotted currentColor.
Сообщение о кукиз с фокусом на ссылке на описание политики сайта, слайдер со старыми каталогами мебели, список ссылок из футера и логотип сайта с надписью Ikea внутри жёлтого овала на синем фоне.
Стили фокуса у ссылок на сайте музея 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. В итоге от продвинутого отказались и оставили только минимальный.
Это один из самых сложных критериев, которые планируют добавить в новую версию WCAG. Сейчас он активно обсуждается и дорабатывается.
Коротко
Когда элемент интерфейса получает фокус с клавиатуры, индикатор фокуса должен:
  • обводить элемент;
  • иметь соотношение контраста минимум 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, а вот для градиентной тени это не важно.
Несколько вариантов кнопок без фокуса и в фокусе. Одна кнопка без фокуса с чёрным фоном, белым текстом «Настройки» и прямыми углами. При фокусе она становится больше, внутри появляется белая жирная рамка, меняется цвет фона на белый, рядом с названием появляется жирная белая вертикальная черта и не такая жирная горизонтальная. Другая кнопка без фокуса с серым фоном, таким же названием и со скруглёнными краями. При фокусе у неё появляется чёрная сплошная и пунктирная рамки снаружи, а ещё размытая серая тень. Последняя кнопка круглая и с иконкой лупы внутри. При фокусе у неё появляется жирная круглая рамка внутри, более тонкая рамка снаружи и двойная рамка со светло-фиолетовой линией внутри и чёрной снаружи.
Варианты стилей фокуса, которые соответствуют критерию 2.4.11.
Если в элемент вложено несколько интерактивных, критерий про внешний вид фокуса распространяется в первую очередь на дочерние элементы. Например, как в кастомном комбинированном списке или в панели вкладок. При этом в случае таких сложных интерактивных элементов фокус может быть:
  • у всего компонента;
  • у вложенных в него компонентов;
  • одновременно у всего компонента и у вложенных в него элементов.
Для ссылок не критично, если индикатор фокуса не сплошной и одна из его сторон скрывается при переносе ссылки. Обычно это происходит, когда используете свойство 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 пикселя. Кнопки с розовым фоном при фокусе меняют свой фон на белый, они обводятся розовой рамкой, а снаружи появляется ещё одна рамка толщиной 3 пикселя.
Несколько видов элементов в состоянии фокуса и без — ссылки и несколько кнопок. Они подробно описаны до картинки.
Стили фокуса у ссылок и кнопок на сайте Fable.
На gov.uk также используют несколько вариантов стилей для фокуса.
Ссылки по умолчанию синие с тонкой чертой такого же цвета под ними. Когда делаете на них фокус, они становятся чёрными, нижнее подчёркивание тоже становится чёрным и более жирным, а фон меняется на жёлтый.
Что касается текстовых полей, по умолчанию вокруг них тонкая чёрная рамка. При фокусе рамка становится более жирной, дополнительно вокруг неё появляется ещё одна жёлтого цвета.
У некоторых кнопок при фокусе фон с серого меняется на жёлтый, а более жирная нижняя граница увеличивается где-то на 3 пикселя.
Несколько видов элементов в состоянии фокуса и без него — поле поиска, ссылки и кнопки. Подробнее описаны до картинки.
Стили кнопок, ссылок и полей на gov.uk.
Примеры барьеров
  • Вокруг названия вкладки при фокусе появляется пунктирная черта с точками, ширина которой 1 пиксель.
  • При фокусе внутри кнопки рядом с текстом появляется вертикальная черта толщиной 1 пиксель.
На сайте музея Ikea при фокусе на ссылках вокруг них появляется тонкая пунктирная рамка светло-серого цвета или тёмно-серого цвета в зависимости от цвета текста. Для неё используется свойство outline со значением 1px dotted currentColor.
Сообщение о кукиз с фокусом на ссылке на описание политики сайта, слайдер со старыми каталогами мебели, список ссылок из футера и логотип сайта с надписью Ikea внутри жёлтого овала на синем фоне.
Стили фокуса у ссылок на сайте музея 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 eb05d45..a84d318 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": "2022-12-18T00:00:00.000Z"
-		}
 
Принципы WCAG. Видимый фокус
  • 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. Видимый фокус
  • 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 ba700aa..063ad91 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": "2023-01-17T00:00:00.000Z"
-		}
 
Принципы WCAG. Информация и взаимосвязи
  • 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. Информация и взаимосвязи
  • 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 e071863..0195f3e 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": "2023-03-07T00: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 6f3d569..ace7363 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. Нетекстовое содержимое
  • 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. Нетекстовое содержимое
  • 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 51d682e..2a56555 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": "2022-12-30T00:00:00.000Z"
-		}
 
Принципы WCAG. Название страницы
  • WCAG
  • HTML
  • Тексты
 
В этом посте из серии про разбор Руководств по доступности веб-контента (Web Content Accessibility Guidelines, коротко WCAG) расскажу про критерий 2.4.2: название страницы.
Это базовый критерий уровня A, который относится к принципу управляемости и к руководству про навигируемость.
Коротко о критерии
У страницы должно быть название, которое описывает её цель или тему.
Подробнее
Название или заголовок страницы — это то, что пользователи видят или слышат, когда взаимодействуют со вкладкой в браузере или со ссылкой в поисковой выдаче. Это один из факторов ранжирования, так что здесь доступность пересекается с SEO.
Конкретно критерий касается атрибута <title> и его содержимого.
Доступные названия кратко и чётко описывают основные темы или цели страниц и документов. Так пользователи быстрее узнают об их содержании и им проще ориентироваться по сайту.
В критерии несколько конкретных требований к названию страниц:
  • Чёткое, понятное и хорошо описывает тему страницы или документа. Лучше использовать простой язык и избегать жаргонизмов и сложных терминов.
  • Динамически меняется вместе с контентом страницы, когда изменяется её тема или цель.
За пределами WCAG есть несколько других хороших практик для названий:
  • Используйте не больше 60 символов. Чем короче название, тем лучше.
  • Не теряет смысл вне контекста страницы.
  • Уникальное и не повторяет полностью названия других страниц.
  • Если используете название сайта, сервиса или компании, перед ними должно идти описание страницы.
  • Не повторяйте много раз одни и те же разделители в одном названии и не используйте их в декоративных целях. Например, несколько тильд (~~~) или плюсов (+++) подряд.
  • Старайтесь придерживаться одинаковых паттернов. Например, если решили использовать длинное тире, используйте его везде.
В названиях страниц можно использовать 1–2 ключевых слова. Если их не будет, это никак не повлияет на доступность или результаты в поисковой выдаче.
Проще всего повторять в <title> содержимое <h1>, но это тоже не обязательное правило. К примеру, в основном заголовке на странице может быть приветствие, которое лучше не использовать в названии.
Название главной страницы не обязательно должно чётко описывать содержимое, так что это исключение из критерия. Для таких страниц можно использовать только название компании, сервиса или сайта.
Когда ссылаетесь на страницу сайта, можно повторить или слегка изменить название страницы в тексте ссылки.
Кому это важно
  • Все пользователи, особенно когда у них в браузере открыто несколько вкладок.
  • Пользователи скринридеров. Благодаря названиям страниц во вкладках им проще перемещаться между ними.
  • Люди с когнитивными особенностями. Особенно те, у кого небольшой объём рабочей памяти, и они легко забывают, на какой вкладке были до этого.
  • Пользователи с особенностями моторики, которые управляют интерфейсом с помощью голоса.
Как избежать барьер
Над названием страниц работают люди, которые создают контент, дизайн или код.
Чтобы выполнить критерий, обязательно используйте тег <title> с содержимым, которое кратко и чётко описывает страницу. Тег размещают внутри <head>.
<!doctype html>
+		}
 
Принципы WCAG. Название страницы
  • 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 d64d51d..64e4bbd 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": "2022-11-07T00:00:00.000Z"
-		}
 
Принципы WCAG. Сенсорные характеристики
  • WCAG
  • Тексты
  • Дизайн
 
В этом посте из серии про разбор Руководств по доступности веб-контента (Web Content Accessibility Guidelines, коротко WCAG) расскажу про критерий 1.3.3: сенсорные характеристики.
Это базовый критерий уровня A, он связан с принципом воспринимаемости и с различимостью содержимого.
Коротко о критерии
Инструкции о том, как взаимодействовать с чем-то на странице, не зависят от сенсорных характеристик элемента — формы, размера, цвета, места, звука и прочего.
Подробнее
Критерий относится к любым инструкциям на сайтах. Это могут быть инструкции к целым формам, звуковые оповещения, подсказки к полям, а может быть просто текст на странице с анонсом новой фичи и рассказом о том, как её использовать.
Когда описываете работу с чем-то, расскажите не только о внешнем виде элемента, а ещё про его название и функции. Так что, принцип подразумевает, что у кнопки или ссылки есть название. Лучше делать его видимым, хотя WCAG разрешает добавлять для кнопок визуально скрытые имена. Они доступны только пользователям вспомогательных технологий.
К примеру, когда пользователь скринридера услышит «Найдите круглую синюю кнопку в левом углу экрана», это не поможет ему найти эту кнопку. Скринридеры не рассказывают о цветах и других стилях элементов, а ещё сложно понять на слух, где право и лево на сайте.
Ещё внешний вид и расположение элементов могут отличаться в зависимости от темы на сайте, размера экрана и при разном освещении и яркости.
Чтобы инструкция про кнопку стала понятной всем, можно рассказать чуть больше про неё: «Найдите круглую синюю кнопку с названием «Следующая страница» в левом углу экрана». Теперь пользователь скринридера знает её название и может найти в списке всех кнопок или перейти к ней без списка.
В инструкциях полезно описывать внешние характеристики элемента. Это помогает некоторым пользователям с когнитивными особенностями и нейроотличиями, так что критерий не призывает рассказывать только о названиях и функциях.
Критерий перекликается с одним из принципов универсального дизайна о легко воспринимаемой информации. Этот принцип требует использовать несколько каналов восприятия — визуальный, аудиальный, тактильный и вербальный.
Несколько примеров инструкций, в которых что-то пошло не так:
  • Больше информации найдёте справа.
  • Если кликните на стрелку, перейдёте к следующему шагу.
  • Важная информация выделена жёлтым цветом.
  • Кликните по круглой синей кнопке в верхнем правом углу.
Что касается «выше» и «ниже», всё зависит от контекста и языка. Пользователям может быть понятно, что содержимое находится до определённой точки или после неё.
Кому это важно
  • Пользователям со слепотой и слабовидящим, которые много полагаются на слух.
  • Пользователям с глухотой и слабослышащим, которым важно видеть содержимое.
  • Пользователям мобильных устройств. Расположение элементов на странице в мобильной версии сайта может отличаться от десктопной.
Как избежать барьер
Этот барьер обычно появляется на этапе информационного дизайна и написания текстов, поэтому хорошо заранее обращать внимание понятность и доступность инструкций.
Разработчики могут следить за названиями элементов в коде и давать кнопкам, ссылкам и другим элементам хотя бы визуально скрытые названия. Также хорошо использовать заголовки для разных частей страницы, например, для бокового меню или списков со ссылками.
Примеры соответствия критерию
  • Форма состоит из нескольких шагов. Чтобы перейти к следующему шагу, надо нажать на фиолетовую кнопку со стрелкой и текстом «Следующий шаг». Кнопка расположена в правом нижнем углу. Снизу формы есть инструкция: «Чтобы перейти к следующему шагу, нажмите на фиолетовую кнопку со стрелкой и названием «Следующий шаг» в правом нижнем углу».
  • В правой части страницы есть список ссылок на тарифные планы. В тексте сказано: «Выберите тарифный план из списка с заголовком «Наши тарифные планы». Он находится справа».
  • При заполнении поля появилась ошибка. В ней использована иконка с крестиком и текст «Вы неправильно заполнили поле. Рекомендуем формат месяц-дата-число».
На сайте Vimeo есть форма регистрации нового пользователя. Если ввёл неправильные данные в поле, под ним появится текст об ошибке, а в поле красная иконка с восклицательным знаком.
Форма с названием «Присоединиться к Vimeo». Выделено поле «Email», в него введена часть почты «myemail@». Рядом с текстом в поле красная иконка с восклицательным знаком в круге. Поле также обведено красной рамкой, под ним красный текст «Введите правильный адрес электронной почты, пожалуйста».
Форма регистрации на Vimeo.
Примеры барьеров
  • На сайте карусель с кнопками со стрелками влево и вправо. В инструкции на странице написано: «Для перехода к следующему товару нажмите на правую кнопку, для возврата — на левую кнопку».
  • На странице есть боковое меню со списком ссылок на другие статьи. В инструкции на странице сказано: «Другие статьи найдёте в боковом меню справа».
  • При заполнении поля появилась ошибка. В ней только иконка с крестиком без видимого или визуально скрытого текста.
  • Страница с тестом. Время для его прохождения ограничено. В инструкции перед тестом написано: «Когда время истечёт, вы услышите сигнал об этом».
  • На странице таблица с разноцветными строками. Под таблицей пояснение: «Зелёные строки в таблице означают прибыль компании в этом месяце, а красные — расходы».
В десктопной версии TikTok есть инструкция о том, как войти в личный аккаунт с помощью QR-кода. В ней используют изображения с иконками кнопок, они никак не подписаны.
Открыто модальное окно с заголовком «Залогиниться с помощью QR-кода». Под заголовком код, рядом с ним скриншот с приложением для телефона. Ещё есть текстовая инструкция из трёх пунктов. Откройте приложение TikTok на своём мобильном устройстве. В профиле тапните, вместо текста иконка со схематичным человеком и крестиком рядом с ним. Тапните, вместо текста иконка с рамкой из пунктирных линий и горизонтальной чертой по центру, и отсканируйте QR-код, чтобы подтвердить ваш вход.
Инструкция для входа в свой аккаунт в TikTok с помощью QR-кода.
Как тестировать
С поиском проблем с сенсорными характеристиками поможет только ручное тестирование.
  • Найдите страницы, где есть инструкции.
  • Убедитесь, что в них описан не только внешний вид элементов и их положение на странице.
Что почитать
Другие статьи
 Татьяна Фокина, 2021–2024
Разработано на 11ty, иконки с Lucide Нашли ошибку? Поделитесь ей на GitHub

\ No newline at end of file
+		}
 
Принципы WCAG. Сенсорные характеристики
  • WCAG
  • Тексты
  • Дизайн
 
В этом посте из серии про разбор Руководств по доступности веб-контента (Web Content Accessibility Guidelines, коротко WCAG) расскажу про критерий 1.3.3: сенсорные характеристики.
Это базовый критерий уровня A, он связан с принципом воспринимаемости и с различимостью содержимого.
Коротко о критерии
Инструкции о том, как взаимодействовать с чем-то на странице, не зависят от сенсорных характеристик элемента — формы, размера, цвета, места, звука и прочего.
Подробнее
Критерий относится к любым инструкциям на сайтах. Это могут быть инструкции к целым формам, звуковые оповещения, подсказки к полям, а может быть просто текст на странице с анонсом новой фичи и рассказом о том, как её использовать.
Когда описываете работу с чем-то, расскажите не только о внешнем виде элемента, а ещё про его название и функции. Так что, принцип подразумевает, что у кнопки или ссылки есть название. Лучше делать его видимым, хотя WCAG разрешает добавлять для кнопок визуально скрытые имена. Они доступны только пользователям вспомогательных технологий.
К примеру, когда пользователь скринридера услышит «Найдите круглую синюю кнопку в левом углу экрана», это не поможет ему найти эту кнопку. Скринридеры не рассказывают о цветах и других стилях элементов, а ещё сложно понять на слух, где право и лево на сайте.
Ещё внешний вид и расположение элементов могут отличаться в зависимости от темы на сайте, размера экрана и при разном освещении и яркости.
Чтобы инструкция про кнопку стала понятной всем, можно рассказать чуть больше про неё: «Найдите круглую синюю кнопку с названием «Следующая страница» в левом углу экрана». Теперь пользователь скринридера знает её название и может найти в списке всех кнопок или перейти к ней без списка.
В инструкциях полезно описывать внешние характеристики элемента. Это помогает некоторым пользователям с когнитивными особенностями и нейроотличиями, так что критерий не призывает рассказывать только о названиях и функциях.
Критерий перекликается с одним из принципов универсального дизайна о легко воспринимаемой информации. Этот принцип требует использовать несколько каналов восприятия — визуальный, аудиальный, тактильный и вербальный.
Несколько примеров инструкций, в которых что-то пошло не так:
  • Больше информации найдёте справа.
  • Если кликните на стрелку, перейдёте к следующему шагу.
  • Важная информация выделена жёлтым цветом.
  • Кликните по круглой синей кнопке в верхнем правом углу.
Что касается «выше» и «ниже», всё зависит от контекста и языка. Пользователям может быть понятно, что содержимое находится до определённой точки или после неё.
Кому это важно
  • Пользователям со слепотой и слабовидящим, которые много полагаются на слух.
  • Пользователям с глухотой и слабослышащим, которым важно видеть содержимое.
  • Пользователям мобильных устройств. Расположение элементов на странице в мобильной версии сайта может отличаться от десктопной.
Как избежать барьер
Этот барьер обычно появляется на этапе информационного дизайна и написания текстов, поэтому хорошо заранее обращать внимание понятность и доступность инструкций.
Разработчики могут следить за названиями элементов в коде и давать кнопкам, ссылкам и другим элементам хотя бы визуально скрытые названия. Также хорошо использовать заголовки для разных частей страницы, например, для бокового меню или списков со ссылками.
Примеры соответствия критерию
  • Форма состоит из нескольких шагов. Чтобы перейти к следующему шагу, надо нажать на фиолетовую кнопку со стрелкой и текстом «Следующий шаг». Кнопка расположена в правом нижнем углу. Снизу формы есть инструкция: «Чтобы перейти к следующему шагу, нажмите на фиолетовую кнопку со стрелкой и названием «Следующий шаг» в правом нижнем углу».
  • В правой части страницы есть список ссылок на тарифные планы. В тексте сказано: «Выберите тарифный план из списка с заголовком «Наши тарифные планы». Он находится справа».
  • При заполнении поля появилась ошибка. В ней использована иконка с крестиком и текст «Вы неправильно заполнили поле. Рекомендуем формат месяц-дата-число».
На сайте Vimeo есть форма регистрации нового пользователя. Если ввёл неправильные данные в поле, под ним появится текст об ошибке, а в поле красная иконка с восклицательным знаком.
Форма с названием «Присоединиться к Vimeo». Выделено поле «Email», в него введена часть почты «myemail@». Рядом с текстом в поле красная иконка с восклицательным знаком в круге. Поле также обведено красной рамкой, под ним красный текст «Введите правильный адрес электронной почты, пожалуйста».
Форма регистрации на Vimeo.
Примеры барьеров
  • На сайте карусель с кнопками со стрелками влево и вправо. В инструкции на странице написано: «Для перехода к следующему товару нажмите на правую кнопку, для возврата — на левую кнопку».
  • На странице есть боковое меню со списком ссылок на другие статьи. В инструкции на странице сказано: «Другие статьи найдёте в боковом меню справа».
  • При заполнении поля появилась ошибка. В ней только иконка с крестиком без видимого или визуально скрытого текста.
  • Страница с тестом. Время для его прохождения ограничено. В инструкции перед тестом написано: «Когда время истечёт, вы услышите сигнал об этом».
  • На странице таблица с разноцветными строками. Под таблицей пояснение: «Зелёные строки в таблице означают прибыль компании в этом месяце, а красные — расходы».
В десктопной версии TikTok есть инструкция о том, как войти в личный аккаунт с помощью QR-кода. В ней используют изображения с иконками кнопок, они никак не подписаны.
Открыто модальное окно с заголовком «Залогиниться с помощью 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 8cecf61..c2b589e 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": "2022-10-31T00:00:00.000Z"
-		}
 
Принципы WCAG. Размер цели
  • 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 на 22 пикселя. Список ссылок «Гёзда», «Хинкали», «Равиоли», их размер 20 пикселей, высота строки 27 пикселей. Кнопка с иконкой в виде трёх параллельных линий, из неё выпал список ссылок с высотой 24 пикселя.
Элементы, которые соответствуют критериям о размере целей.
Кнопка с иконкой со стрелкой вниз, направленная на линию с приподнятыми краями, её размер 23 на 23 пикселя. Две кнопки размером 22 на 22 пикселя, между ними нет пустого пространства. Список ссылок «Гёзда», «Хинкали», «Равиоли», их размер 20 пикселей, высота строки 21 пиксель. Кнопка с иконкой в виде трёх параллельных линий, из неё выпал список ссылок с высотой 21 пиксель.
Элементы, которые нарушают критерии о размере целей.
Почему такие размеры целей
За рекомендуемыми размерами интерактивных элементов стоит несколько исследований.
В 2005 MIT Touch Lab проводила исследования на тему размера пальцев рук людей (PDF). Результаты показали, что средний размер указательных пальцев взрослых людей 1.6–2 сантиметра, а большого пальца — 2.5 сантиметра. Если переводить это в пиксели, получится 45–57 пикселей и 72 пикселя соответственно.
В 2006 Пекка Фархи, Эми Карлсон и Бенджамин Бедерсон установили оптимальный размер целей на сенсорном экране, если взаимодействовать с ним одной рукой. Это минимум 1 на 1 сантиметр. Если переводить сантиметры в пиксели, получится 28 на 28 пикселей. Также они выяснили, что чем больше размер интерактивного элемента на экране, тем меньше ошибок совершают пользователи. Это же показало другое исследование дизайна сенсорных клавиш для выбора цели на мобильном телефоне (PDF).
Кому это важно
  • Пользователи с особенностями устройства скелета и мышц — c церебральным параличом, мышечной дистрофией, артритом.
  • Пользователи с особенностями мелкой моторики — с тремором из-за рассеянного склероза, болезни Паркинсона, инсультом, диспраксией и другими состояниями.
  • Пользователи с пониженным, сниженным зрением или слабовидящие.
  • Пользователи с крупными пальцами.
  • Все пользователи мобильных устройств, особенно когда они пользуются ими в транспорте или на ходу.
Как избежать барьер
Критерии в основном связаны с дизайном, так что в первую очередь важно всё продумать на этом этапе.
В коде проблему с небольшими кнопками можно исправить, если увеличить область клика. Есть несколько способов. Например с помощью padding или min-width и min-height.
button {
+		}
 
Принципы WCAG. Размер цели
  • 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 на 22 пикселя. Список ссылок «Гёзда», «Хинкали», «Равиоли», их размер 20 пикселей, высота строки 27 пикселей. Кнопка с иконкой в виде трёх параллельных линий, из неё выпал список ссылок с высотой 24 пикселя.
Элементы, которые соответствуют критериям о размере целей.
Кнопка с иконкой со стрелкой вниз, направленная на линию с приподнятыми краями, её размер 23 на 23 пикселя. Две кнопки размером 22 на 22 пикселя, между ними нет пустого пространства. Список ссылок «Гёзда», «Хинкали», «Равиоли», их размер 20 пикселей, высота строки 21 пиксель. Кнопка с иконкой в виде трёх параллельных линий, из неё выпал список ссылок с высотой 21 пиксель.
Элементы, которые нарушают критерии о размере целей.
Почему такие размеры целей
За рекомендуемыми размерами интерактивных элементов стоит несколько исследований.
В 2005 MIT Touch Lab проводила исследования на тему размера пальцев рук людей (PDF). Результаты показали, что средний размер указательных пальцев взрослых людей 1.6–2 сантиметра, а большого пальца — 2.5 сантиметра. Если переводить это в пиксели, получится 45–57 пикселей и 72 пикселя соответственно.
В 2006 Пекка Фархи, Эми Карлсон и Бенджамин Бедерсон установили оптимальный размер целей на сенсорном экране, если взаимодействовать с ним одной рукой. Это минимум 1 на 1 сантиметр. Если переводить сантиметры в пиксели, получится 28 на 28 пикселей. Также они выяснили, что чем больше размер интерактивного элемента на экране, тем меньше ошибок совершают пользователи. Это же показало другое исследование дизайна сенсорных клавиш для выбора цели на мобильном телефоне (PDF).
Кому это важно
  • Пользователи с особенностями устройства скелета и мышц — c церебральным параличом, мышечной дистрофией, артритом.
  • Пользователи с особенностями мелкой моторики — с тремором из-за рассеянного склероза, болезни Паркинсона, инсультом, диспраксией и другими состояниями.
  • Пользователи с пониженным, сниженным зрением или слабовидящие.
  • Пользователи с крупными пальцами.
  • Все пользователи мобильных устройств, особенно когда они пользуются ими в транспорте или на ходу.
Как избежать барьер
Критерии в основном связаны с дизайном, так что в первую очередь важно всё продумать на этом этапе.
В коде проблему с небольшими кнопками можно исправить, если увеличить область клика. Есть несколько способов. Например с помощью padding или min-width и min-height.
button {
     font-size: 14px;
     padding: 20px;
 }
ul li {
diff --git a/ru/index.html b/ru/index.html
index e218597..75d9235 100644
--- a/ru/index.html
+++ b/ru/index.html
@@ -1 +1 @@
-Блог о цифровой доступности
 
Статьи про цифровую доступность
Привет, я Татьяна Фокина, но вы можете звать меня просто Таня. Я специалистка по веб-доступности, которая любит создавать дружелюбные интерфейсы и обсуждать цифровую доступность с другими (иногда посреди ночи).
В этом блоге делюсь практическими советами, хаками, полезными ссылками, своими мыслями и просто интересными находками о доступной разработке и инклюзии ✨
Если хотите спросить меня о моих статьях или доступности, ищите меня на LinkedIn или в Твиттере.
Недавние статьи
Клавиатура
Разбираемся с критерием WCAG про доступность интерфейса для клавиатуры.
  • WCAG
  • Клавиатура
  • HTML
 
Внешний вид фокуса
Как должны выглядеть элементы при фокусе с клавиатуры по мнению WCAG 2.2.
  • WCAG
  • Дизайн
  • CSS
  • Клавиатура
 
Все статьи
 Татьяна Фокина, 2021–2024
Разработано на 11ty, иконки с Lucide Нашли ошибку? Поделитесь ей на GitHub

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

\ No newline at end of file
diff --git a/styles/styles.css b/styles/styles.css
index a7e608a..33ed8a9 100644
--- a/styles/styles.css
+++ b/styles/styles.css
@@ -1 +1 @@
-.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{font-size:var(--step-0);color:var(--text-color);background:var(--bg-color);flex-direction:column;min-height:100vh;margin:0;font-family:IBM Plex Sans,Arial,Helvetica,sans-serif;line-height:1.6;transition:all 1s;display:flex}.wrapper{width:100%;max-width:780px;margin:0 auto;padding:0 20px}.base__body{flex:1 0 auto;padding-top:60px}@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")}:root{--step-3:2rem;--step-2:1.75rem;--step-1:1.4375rem;--step-0:1.0625rem;--step--1:.9375rem;--step--2:.625rem}@media (width>=768px){:root{--step-3:2.75rem;--step-2:2.375rem;--step-1:1.75rem;--step-0:1.25rem;--step--1:1rem;--step--2:.875rem}}.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:20px 0;line-height:1.6}p:first-child{margin-top:0}p:last-child{margin-bottom:0}hr{border:0;width:100%;height:15px;margin:40px auto;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}hr+p{margin-top:0}figure{margin:0}figcaption{font-size:var(--step--1);padding-top:8px}figure+figure{margin-top:40px}ul+figure,ol+figure{margin-top:20px}ul:has(a) li{padding:3px 0}small{font-size:var(--step--1)}code{font-family:IBM Plex Mono,Courier New,monospace;font-size:var(--step--1);word-wrap:break-word;color:var(--text-color);background:var(--code-color);border-radius:4px;padding:.15rem}a>code{padding:.03rem}pre code{padding:36px;display:block;overflow-x:auto}pre+ul{padding-top:20px}kbd{font-family:IBM Plex Mono,Courier New,monospace}samp{font-family:IBM Plex Sans,Arial,Helvetica,sans-serif}blockquote{border-left:4px solid var(--border-color);word-wrap:break-word}blockquote,blockquote ol,blockquote ul{margin:0;padding-left:24px}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}h1{font-size:var(--step-3);margin-top:0;margin-bottom:40px;line-height:1.318}h2{font-size:var(--step-2);margin-top:48px;margin-bottom:16px;line-height:1.263}h3{font-size:var(--step-1);margin-top:32px;margin-bottom:15px;line-height:1.285}h4{margin-top:28px;margin-bottom:14px;line-height:1.5}img{filter:var(--img-filter);border-radius:4px;max-width:100%;height:auto;display:block}@media (forced-colors:active){::selection{background:highlight}a:hover{color:canvas;background-color: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;margin-bottom:64px}.article-header__dates{justify-content:center;gap:16px;margin-top:16px;display:flex}.article-header__dates-item{font-size:var(--step--1);align-items:center;gap:4px;display:flex}.article__note{font-size:var(--step--1);background:var(--bg-part-color);border-radius:4px;margin:20px 0;padding:20px;display:flex;position:relative}.article__note-text{font-size:var(--step--1);word-break:break-word;margin:0;padding-left:32px}.article__note-icon{display:block;position:absolute;top:20px}.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;padding:0;list-style:none;display:flex}.navigation__list-item-link{border-bottom:0;align-items:center;gap:8px;width:100%;padding:12px;line-height:1.7;transition:color .2s;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}}.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{font-size:var(--step--2);color:var(--text-color);cursor:pointer;background:0 0;border:2px solid #0000;border-radius:32px;margin:0;padding:12px 16px;transition:background .2s}.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%;display:inline-flex}.cards--w-margin{margin-top:32px;margin-bottom:24px}.cards--in-article{margin:0;padding:0}@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;transition:background .3s;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;transition:none}.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}.cards__item-details{align-items:center;gap:8px;display:inline-flex}.cards__item-description{margin:0}.cards__item-date{font-size:var(--step--1);align-items:center;gap:4px;display:inline-flex}.topics{flex-wrap:wrap;gap:4px;padding:0;list-style:none;display:flex}.topics--in-article{justify-content:center}.topics--in-card{margin-bottom:12px}.topics__item{font-size:var(--step--2);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{font-size:var(--step-0);color:var(--text-color);background:var(--bg-color);flex-direction:column;min-height:100vh;margin:0;font-family:IBM Plex Sans,Arial,Helvetica,sans-serif;line-height:1.6;display:flex}.wrapper{width:100%;max-width:780px;margin:0 auto;padding:0 20px}.base__body{flex:1 0 auto;padding-top:60px}@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")}:root{--step-3:2rem;--step-2:1.75rem;--step-1:1.4375rem;--step-0:1.0625rem;--step--1:.9375rem;--step--2:.625rem}@media (width>=768px){:root{--step-3:2.75rem;--step-2:2.375rem;--step-1:1.75rem;--step-0:1.25rem;--step--1:1rem;--step--2:.875rem}}.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:20px 0;line-height:1.6}p:first-child{margin-top:0}p:last-child{margin-bottom:0}hr{border:0;width:100%;height:15px;margin:40px auto;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}hr+p{margin-top:0}figure{margin:0}figcaption{font-size:var(--step--1);padding-top:8px}figure+figure{margin-top:40px}ul+figure,ol+figure{margin-top:20px}ul:has(a) li{padding:3px 0}small{font-size:var(--step--1)}code{font-family:IBM Plex Mono,Courier New,monospace;font-size:var(--step--1);word-wrap:break-word;color:var(--text-color);background:var(--code-color);border-radius:4px;padding:.15rem}a>code{padding:.03rem}pre code{padding:36px;display:block;overflow-x:auto}pre+ul{padding-top:20px}kbd{font-family:IBM Plex Mono,Courier New,monospace}samp{font-family:IBM Plex Sans,Arial,Helvetica,sans-serif}blockquote{border-left:4px solid var(--border-color);word-wrap:break-word}blockquote,blockquote ol,blockquote ul{margin:0;padding-left:24px}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}h1{font-size:var(--step-3);margin-top:0;margin-bottom:40px;line-height:1.318}h2{font-size:var(--step-2);margin-top:48px;margin-bottom:16px;line-height:1.263}h3{font-size:var(--step-1);margin-top:32px;margin-bottom:15px;line-height:1.285}h4{margin-top:28px;margin-bottom:14px;line-height:1.5}img{filter:var(--img-filter);border-radius:4px;max-width:100%;height:auto;display:block}@media (forced-colors:active){::selection{background:highlight}a:hover{color:canvas;background-color: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;margin-bottom:64px}.article-header__dates{justify-content:center;gap:16px;margin-top:16px;display:flex}.article-header__dates-item{font-size:var(--step--1);align-items:center;gap:4px;display:flex}.article__note{font-size:var(--step--1);background:var(--bg-part-color);border-radius:4px;margin:20px 0;padding:20px;display:flex;position:relative}.article__note-text{font-size:var(--step--1);word-break:break-word;margin:0;padding-left:32px}.article__note-icon{display:block;position:absolute;top:20px}.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;padding:0;list-style:none;display:flex}.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}}.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{font-size:var(--step--1);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%;display:inline-flex}.cards--w-margin{margin-top:32px;margin-bottom:24px}.cards--in-article{margin:0;padding:0}@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}.cards__item-details{align-items:center;gap:8px;display:inline-flex}.cards__item-description{margin:0}.cards__item-date{font-size:var(--step--1);align-items:center;gap:4px;display:inline-flex}.topics{flex-wrap:wrap;gap:4px;padding:0;list-style:none;display:flex}.topics--in-article{justify-content:center}.topics--in-card{margin-bottom:12px}.topics__item{font-size:var(--step--2);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 e04b3ef..e36df29 100644
--- a/styles/styles.css.map
+++ b/styles/styles.css.map
@@ -1 +1 @@
-{"version":3,"sourceRoot":"","sources":["../../src/styles/basic/_color-themes.scss","../../src/styles/basic/_layout.scss","../../src/styles/_variables.scss","../../src/styles/basic/_fonts.scss","../../src/styles/basic/_typography.scss","../../src/styles/_mixins-and-functions.scss","../../src/styles/basic/_global.scss","../../src/styles/basic/_text.scss","../../src/styles/basic/_links.scss","../../src/styles/basic/_headings.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":"AAGA;EACC;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;;;AAID;EACC;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;;;AC1BD;EACC;EACA;;;AAGD;EACC;EACA;EACA;EACA;EACA;EACA,aCUkB;EDTlB,aCYkB;EDXlB;EACA;EACA;;;AAGD;EACC;EACA;EACA;EACA;EACA;EACA,cCYQ;EDXR,eCWQ;;;ADRT;EACC;EACA;;;AEhCD;EACC;EACA;EACA;EACA;EACA;;AAKD;EACC;EACA;EACA;EACA;EACA;;AAKD;EACC;EACA;EACA;EACA;EACA;;ACvBD;EACC;EACA;EACA;EACA;EACA;EACA;;ACHA;EDHD;IASE;IACA;IACA;IACA;IACA;IACA;;;;AEdF;EACC;EACA;EACA;EACA;EACA;EACA;EACA;EACA;;;AAGD;EACC;EACA;;ADVA;ECQD;IAKE;;;;ACZF;EACC;;;AAGD;EACC;EACA,aLckB;;AKZlB;EACC;;AAGD;EACC;;;AAIF;EACC;EACA;EACA;EACA,QAvBW;EAwBX;EACA;;AAEA;EACC;EACA;EACA;EACA;EACA;EACA;EACA,QAlCU;EAmCV;EACA;EACA;;;AAIF;EACC;;;AAGD;EACC;;;AAGD;EACC,aLnBQ;EKoBR;;;AAGD;EACC,YLhBS;;;AKmBV;AAAA;EAEC,YL1BQ;;;AK6BT;EACC;;;AAGD;EACC;;;AAGD;EACC,SA1EkB;EA2ElB,aLrDkB;EKsDlB;EACA;EACA;EACA;EACA;;;AAGD;EACC,SAnFoB;;;AAsFrB;EACC;EACA,SLjDQ;EKkDR;;;AAGD;EACC,aL1DQ;;;AK6DT;EACC,aL5EkB;;;AK+EnB;EACC,aLjFkB;;;AKoFnB;EACC;EACA;;;AAGD;AAAA;AAAA;EAGC;EACA,cL7EQ;;;AMtCT;EACC;EACA;EACA;;AAEA;EACC;;AAGD;EHEA,eADoB;EAEpB,gBGDW;EHEX,eAHuE;EAIvE,eAJ0C;EGGzC;;;ACLF;EACC;EACA,eAVkB;EAWlB;EACA,aPcgB;;;AOXjB;EACC,YAfe;EAgBf,eAfkB;EAgBlB;EACA,aPQgB;;;AOLjB;EACC,YApBe;EAqBf,eApBkB;EAqBlB;EACA,aPEgB;;;AOCjB;EACC,YAzBe;EA0Bf,eAzBkB;EA0BlB,aPHgB;;;AQ5BjB;EACC;EACA;EACA;EACA;EACA;;;ACJD;EACC;IACC;;EAGD;IACC;IACA;;EAGD;IACC;;EAGD;INLA,eMOU;INNV,gBMOW;INNX,eAHuE;IAIvE,eMMU;;EAIV;IACC;;;AAKF;EACC;AAAA;IAEC;;;AChCF;EACC;EACA;;;AAGD;EACC;EACA;EACA,YV2BQ;EU1BR,KV0BQ;;;AUvBT;EACC;EACA;EACA,KViBQ;EUhBR;;;AAGD;EACC;EACA;EACA;EACA,SVaQ;EUZR;EACA;EACA;;;AAGD;EACC;EACA,cVQQ;EUPR;EACA;;;AAGD;EACC;EACA;EACA,KVHQ;;;AWpCT;EACC;EACA;EACA;EACA,KXiCQ;;AGlCR;EQHD;IAOE;IACA,KX+BO;;;;AYvCT;EACC;EACA;EACA;EACA;EACA;EACA,KZ6BQ;;AGhCR;ESHD;IASE;;;;AAIF;EACC;EACA;EACA;EACA;EACA;;;AAGD;EACC;EACA;EACA;EACA;EACA,SZQQ;EYPR,KZMQ;EYLR,aZCuB;EYAvB;EACA;;AAEA;EACC;EACA;;AT/BD;ESkBD;IAiBE,SZFO;;;;AapCT;EACC;EACA;EACA;EACA;;AAEA;EACC;;AAGD;EACC;;AAGD;EVJA,eADoB;EAEpB,gBUKW;EVJX,eAHuE;EAIvE,eAJ0C;;AAN1C;EUHD;IAqBE;;;;AAIF;EACC;EACA;;AVxBA;EUsBD;IAKE;;;;AAIF;EACC;;;ACnCD;EACC;EACA,Sd8BQ;Ec7BR,gBd6BQ;Ec5BR;EACA;EACA;;;AAGD;EACC;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;;AAEA;EACC;;AAGD;EACC;;AAGD;EXlBA,eADoB;EAEpB,gBWmBW;EXlBX,eAHuE;EAIvE,eWkBU;;AAIV;EXzBA,eADoB;EAEpB,gBW0BW;EXzBX,eAHuE;EAIvE,eAJ0C;;AAN1C;EWMD;IAiCE;;;;AAIF;EACC;EACA;;AAEA;EACC;EACA;;;AAIF;EACC;;AAEA;EACC;EACA;;;AC7DF;EACC;EACA;EACA;EACA;EACA;EACA,afsCS;EerCT,gBfmCS;;;AehCV;EACC;EACA;EACA;EACA,KfmBQ;;AG9BR;EYOD;IAOE;;;;ACjBF;EACC;EACA;EACA;EACA,KhBgCQ;;;AgB7BT;EACC,YhB+BQ;EgB9BR,ehB4BQ;;;AgBzBT;EACC;EACA;;AbXA;EaSD;IAKE;;;;AAIF;EACC;EACA;EACA;EACA;EACA;EACA,ShBQQ;EgBPR,KhBOQ;EgBNR;EACA;EACA;;AAEA;EACC;EACA;;AAGD;EACC;;AbpCD;EakBD;IAsBE,ShBFQ;;;;AgBMV;EACC;EACA,ShBbQ;;;AgBgBT;EACC;;;AAGD;Eb9CC,eagDS;Eb/CT,gBagDU;Eb/CV,eAHuE;EAIvE,eAJ0C;;;AasD3C;AAAA;EAEC;;;AAGD;AAAA;EAEC;EACA;EACA;EACA;;AAEA;AAAA;EACC;EACA;EACA;EACA;EACA;EACA;;AAGD;AAAA;EACC;EACA;EACA;;;AAIF;EACC;EACA;EACA,KhB7DQ;;;AgBgET;EACC;;;AAGD;EACC;EACA;EACA,KhBxEQ;EgByER;;;ACzGD;EACC;EACA;EACA,KjB6BQ;EiB5BR;EACA;;;AAGD;EACC;;;AAGD;EACC,ejBqBQ;;;AiBlBT;EACC;EACA;EACA;EACA;EACA","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/_variables.scss","../../src/styles/basic/_fonts.scss","../../src/styles/basic/_typography.scss","../../src/styles/_mixins-and-functions.scss","../../src/styles/basic/_global.scss","../../src/styles/basic/_text.scss","../../src/styles/basic/_links.scss","../../src/styles/basic/_headings.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;;;ACXF;EACC;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;;;AAID;EACC;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;;;AC1BD;EACC;EACA;;;AAGD;EACC;EACA;EACA;EACA;EACA;EACA,aCUkB;EDTlB,aCYkB;EDXlB;EACA;;;AAGD;EACC;EACA;EACA;EACA;EACA;EACA,cCaQ;EDZR,eCYQ;;;ADTT;EACC;EACA;;;AE/BD;EACC;EACA;EACA;EACA;EACA;;AAKD;EACC;EACA;EACA;EACA;EACA;;AAKD;EACC;EACA;EACA;EACA;EACA;;ACxBD;EACC;EACA;EACA;EACA;EACA;EACA;;ACFA;EDJD;IASE;IACA;IACA;IACA;IACA;IACA;;;;AEbF;EACC;EACA;EACA;EACA;EACA;EACA;EACA;EACA;;;AAGD;EACC;EACA;;ADVA;ECQD;IAKE;;;;ACbF;EACC;;;AAGD;EACC;EACA,aLekB;;AKblB;EACC;;AAGD;EACC;;;AAIF;EACC;EACA;EACA;EACA,QAvBW;EAwBX;EACA;;AAEA;EACC;EACA;EACA;EACA;EACA;EACA;EACA,QAlCU;EAmCV;EACA;EACA;;;AAIF;EACC;;;AAGD;EACC;;;AAGD;EACC,aLlBQ;EKmBR;;;AAGD;EACC,YLfS;;;AKkBV;AAAA;EAEC,YLzBQ;;;AK4BT;EACC;;;AAGD;EACC;;;AAGD;EACC,SA1EkB;EA2ElB,aLpDkB;EKqDlB;EACA;EACA;EACA;EACA;;;AAGD;EACC,SAnFoB;;;AAsFrB;EACC;EACA,SLhDQ;EKiDR;;;AAGD;EACC,aLzDQ;;;AK4DT;EACC,aL3EkB;;;AK8EnB;EACC,aLhFkB;;;AKmFnB;EACC;EACA;;;AAGD;AAAA;AAAA;EAGC;EACA,cL5EQ;;;AMtCT;EACC;EACA;EACA;;AAEA;EACC;;AAGD;EHEA,eADoB;EAEpB,gBGDW;EHEX,eAHuE;EAIvE,eAJ0C;EGGzC;;;ACLF;EACC;EACA,eAVkB;EAWlB;EACA,aPcgB;;;AOXjB;EACC,YAfe;EAgBf,eAfkB;EAgBlB;EACA,aPQgB;;;AOLjB;EACC,YApBe;EAqBf,eApBkB;EAqBlB;EACA,aPEgB;;;AOCjB;EACC,YAzBe;EA0Bf,eAzBkB;EA0BlB,aPHgB;;;AQ7BjB;EACC;EACA;EACA;EACA;EACA;;;ACJD;EACC;IACC;;EAGD;IACC;IACA;;EAGD;IACC;;EAGD;INJA,eMMU;INLV,gBMMW;INLX,eAHuE;IAIvE,eMKU;;EAIV;IACC;;;AAKF;EACC;AAAA;IAEC;;;AChCF;EACC;EACA;;;AAGD;EACC;EACA;EACA,YV4BQ;EU3BR,KV2BQ;;;AUxBT;EACC;EACA;EACA,KVkBQ;EUjBR;;;AAGD;EACC;EACA;EACA;EACA,SVcQ;EUbR;EACA;EACA;;;AAGD;EACC;EACA,cVSQ;EURR;EACA;;;AAGD;EACC;EACA;EACA,KVFQ;;;AWpCT;EACC;EACA;EACA;EACA,KXiCQ;;AGlCR;EQHD;IAOE;IACA,KX+BO;;;;AYvCT;EACC;EACA;EACA;EACA;EACA;EACA,KZ6BQ;;AGhCR;ESHD;IASE;;;;AAIF;EACC;EACA;EACA;EACA;EACA;;;AAGD;EACC;EACA;EACA;EACA;EACA,SZQQ;EYPR,KZMQ;EYLR,aZCuB;EYAvB;;AAEA;EACC;EACA;;AT9BD;ESkBD;IAgBE,SZDO;;;;AapCT;EACC;EACA;EACA;EACA;;AAEA;EACC;;AAGD;EACC;;AAGD;EVJA,eADoB;EAEpB,gBUKW;EVJX,eAHuE;EAIvE,eAJ0C;;AAN1C;EUHD;IAqBE;;;;AAIF;EACC;EACA;;AVxBA;EUsBD;IAKE;;;;AAIF;EACC;;;ACnCD;EACC;EACA,Sd8BQ;Ec7BR,gBd6BQ;Ec5BR;EACA;EACA;;;AAGD;EACC;EACA;EACA;EACA;EACA;EACA;EACA;EACA;;AAEA;EACC;;AAGD;EACC;;AAGD;EXjBA,eADoB;EAEpB,gBWkBW;EXjBX,eAHuE;EAIvE,eWiBU;;AAIV;EXxBA,eADoB;EAEpB,gBWyBW;EXxBX,eAHuE;EAIvE,eAJ0C;;AAN1C;EWMD;IAgCE;;;;AAIF;EACC;EACA;;AAEA;EACC;EACA;;;AAIF;EACC;;AAEA;EACC;EACA;;;AC5DF;EACC;EACA;EACA;EACA;EACA;EACA,afsCS;EerCT,gBfmCS;;;AehCV;EACC;EACA;EACA;EACA,KfmBQ;;AG9BR;EYOD;IAOE;;;;ACjBF;EACC;EACA;EACA;EACA,KhBgCQ;;;AgB7BT;EACC,YhB+BQ;EgB9BR,ehB4BQ;;;AgBzBT;EACC;EACA;;AbXA;EaSD;IAKE;;;;AAIF;EACC;EACA;EACA;EACA;EACA;EACA,ShBQQ;EgBPR,KhBOQ;EgBNR;EACA;;AAEA;EACC;EACA;;AAGD;EACC;;AbnCD;EakBD;IAqBE,ShBDQ;;;;AgBKV;EACC;EACA,ShBZQ;;;AgBeT;EACC;;;AAGD;Eb7CC,ea+CS;Eb9CT,gBa+CU;Eb9CV,eAHuE;EAIvE,eAJ0C;;;AaqD3C;AAAA;EAEC;;;AAGD;AAAA;EAEC;EACA;EACA;;AAEA;AAAA;EACC;EACA;EACA;EACA;EACA;EACA;;AAGD;AAAA;EACC;EACA;EACA;;;AAIF;EACC;EACA;EACA,KhB3DQ;;;AgB8DT;EACC;;;AAGD;EACC;EACA;EACA,KhBtEQ;EgBuER;;;ACxGD;EACC;EACA;EACA,KjB8BQ;EiB7BR;EACA;;;AAGD;EACC;;;AAGD;EACC,ejBsBQ;;;AiBnBT;EACC;EACA;EACA;EACA;EACA","file":"styles.css"}
\ No newline at end of file