diff --git a/en/404/index.html b/en/404/index.html index daa85c0..f4407b8 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 e75c705..f2b45b5 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
Published —

Recently, I discovered by chance that an 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 is 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 a button element has a 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 theaccessibility 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 the role attribute
  • Multiple values are listed with spaces between them
  • Multiple roles are needed for fallback. If the first role is not supported or does not 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 the 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 is better never to do this. It 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
 Published — 
Recently, I discovered by chance that an 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 is 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 a button element has a 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 theaccessibility 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 the role attribute
  • Multiple values are listed with spaces between them
  • Multiple roles are needed for fallback. If the first role is not supported or does not 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 the 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 is better never to do this. It 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"
@@ -45,4 +45,4 @@
   tabindex="1"
 >
   Something criminal is going on here
-</div>
  • NVDA with Chrome has nothing to announced
  • NVDA with Firefox has nothing to announced
  • VoiceOver with Safari announced "This is not a button". So, only the content of the aria-label attribute is announced.
In Chrome, for the div element with role="tapir opossum", the computed role is generic. In Firefox, it is a leaf role. In Safari, no suitable role is found.
generic is the implicit role of any divs. This means it is a nameless container for elements without semantic meaning. A text leaf role indicates some kind of textual content.
In all three browsers, aria-label provides the accessibility name "This is not a button", the computed roles are generic, text leaf, in one case "No suitable ARIA roles".
Role attribute with two wrong values from accessibility tree preview in Chrome, Firefox and Safari DevTools.
Conclusion: If both values are invalid, either the element's implicit role is a part of accessibility tree, or nothing is computed. It depends on the browser.
Wrapping up
All this time, WAI-ARIA has allowed the role attribute to have more than one value, but it has not particularly advertised this feature.
I do not think this is a terrible oversight in the specification. It is hard to imagine which roles would need fallbacks in all modern browsers. Moreover, the role attribute is already easy to get confused with. When you have the ability to assign an infinite number of roles, it further complicates the markup and can lead to unexpected errors.
Read more
Other articles
© Tatiana Fokina, 2021–2024 Icons are from Iconfinder. Build on 11ty. Find an issue? Let me know on GitHub

\ No newline at end of file
+</div>
  • NVDA with Chrome has nothing to announced
  • NVDA with Firefox has nothing to announced
  • VoiceOver with Safari announced "This is not a button". So, only the content of the aria-label attribute is announced.

In Chrome, for the div element with role="tapir opossum", the computed role is generic. In Firefox, it is a leaf role. In Safari, no suitable role is found.

generic is the implicit role of any divs. This means it is a nameless container for elements without semantic meaning. A text leaf role indicates some kind of textual content.

In all three browsers, aria-label provides the accessibility name "This is not a button", the computed roles are generic, text leaf, in one case "No suitable ARIA roles".

Role attribute with two wrong values from accessibility tree preview in Chrome, Firefox and Safari DevTools.

Conclusion: If both values are invalid, either the element's implicit role is a part of accessibility tree, or nothing is computed. It depends on the browser.

Wrapping up

All this time, WAI-ARIA has allowed the role attribute to have more than one value, but it has not particularly advertised this feature.

I do not think this is a terrible oversight in the specification. It is hard to imagine which roles would need fallbacks in all modern browsers. Moreover, the role attribute is already easy to get confused with. When you have the ability to assign an infinite number of roles, it further complicates the markup and can lead to unexpected errors.

Read more

Other articles

\ No newline at end of file diff --git a/en/articles/aria-live-regions/index.html b/en/articles/aria-live-regions/index.html index 1d960f2..30b23e4 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
Published —

(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
 Published — 
(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">
@@ -79,4 +79,4 @@
 </p>
 
 <button type="button">Next dish</button>
Now a screen reader will read out the whole sentence, not just the part that changes after the button is clicked.
Aria-relevant
The purpose of this attribute is to tell assistive technologies exactly what changes have taken place on the page and therefore in the accessibility tree. This could be removing old content or adding new content. The attribute is optional.
aria-relevant="" can contain one or more values separated by a space.
  • additions - new information has been added to the page.
  • removals - information has been removed.
  • text - new text or equivalent information has been added, such as the new content of the alt attribute.
  • additions text (default value) indicates that a text has been changed and there's a piece of new information on the page.
  • all - all possible values. Equivalent to the additions removals text value.
In fact, there are few real-world scenarios for using this attribute. It either doesn't work in many browsers and screen readers, or it's advised not to use it at all and use alternative methods.
The most realistic scenario for using it is a friends list. When a friend has gone offline and is no longer available, we can use this attribute to let a user know. We need to set aria-relevant="all" for the list. Then some screen readers will announce that a contact has been deleted. This works in JAWS when a child item is deleted (it no longer works with a parent item). VoiceOver and NVDA aren't affected by this attribute.
Aria-busy
aria-busy="" lets assistive technologies know whether an element's content is currently being updated or not. The attribute makes sense to apply when the page is auto-updating content. Something has been removed, something has been added, some part of it has been changed, and we need to be informed about it all at once in one go. This can be useful when our page has sports statistics that are updated in real-time, a text document that can be edited by several people, some news widget or a weather widget.
aria-busy="" has two values, false and true.
  • false (default value) - with this value, assistive technologies don't wait for changes to complete.
  • true - this value tells assistive technologies that they need to wait until an element has finished changing, at which point they can collect all changes and make an announcement. That is, while the content is updating, screen reader users, for example, won't be able to read that updating part.
In the example below, we have sports scores that are updated regularly during competitions:
<h2>Current score</h2>
-<p role="score" aria-live="polite" aria-busy="true">9:0</p>
To ensure that all information is declared after all changes, we'll first add aria-busy attribute with a value of true and then use JavaScript to replace its value with false or remove it altogether when all changes are complete.
Summary
If you have a part of your page whose content changes, you need to make it an interactive area. Screen readers will then be able to keep their users informed about all the changes. You can make such a part interactive by using role="alert", role="status", role="log", role="marquee", role="timer" and aria-live attribute.
Use role="alert" for important errors and warnings. For better compatibility, add it for necessary elements together with the aria-live="assertive" and aria-atomic="true" attribute (optional).
role="status" is suitable for reporting less important errors and warnings. For example, an autosave message, an incorrectly filled field, and the like. This role should be combined with the aria-live="polite" attribute for compatibility.
If you need to make message history, error list and anything where the sequence of information updates is important, use role="log". For greater compatibility, use the aria-live="polite" attribute along with it.
When you have tickers, currency rates or any other element on your page where information changes quickly, then set role="marquee" for them. For compatibility, supplement it with aria-live="off".
For a timer, counter or stopwatch set role="timer". Don't forget aria-live="off" for better compatibility.
aria-live="" is responsible for how urgently changes need to be announced. Where changes don't need to be announced, use aria-live="off". In most cases there's no urgency to announce changes, so aria-live="polite" comes in handy. Sometimes, when it's an important message, such as a server error, you can use aria-live="assertive".
aria-atomic="" is an optional attribute. It affects whether a screen reader announces a context or only announces changes. By default, all elements are set to aria-atomic="false", meaning screen readers only report content changes. If you change it to aria-atomic="true", screen readers will read out the whole thing, including the unchanged part. In most cases, there's no need to change the default behaviour.
Another optional attribute is aria-relevant="". It is needed to define the type of content changes. It has several values, which can be listed with a space. There are few real-world usage scenarios (deleting or adding a friend to your friend list), and many A screen readers ignore it.
The last optional attribute is aria-busy="". Tells assistive technologies whether the element's content is currently being updated or not. By default, elements are set to aria-busy="false". Screen readers announce changes without waiting for them to complete. In some cases, you can use aria-busy="true" when you want to wait for all updates. May be useful for sports statistics or a text document in group edit mode.
Further reading
Other articles
© Tatiana Fokina, 2021–2024 Icons are from Iconfinder. Build on 11ty. Find an issue? Let me know on GitHub

\ No newline at end of file
+<p role="score" aria-live="polite" aria-busy="true">9:0</p>

To ensure that all information is declared after all changes, we'll first add aria-busy attribute with a value of true and then use JavaScript to replace its value with false or remove it altogether when all changes are complete.

Summary

If you have a part of your page whose content changes, you need to make it an interactive area. Screen readers will then be able to keep their users informed about all the changes. You can make such a part interactive by using role="alert", role="status", role="log", role="marquee", role="timer" and aria-live attribute.

Use role="alert" for important errors and warnings. For better compatibility, add it for necessary elements together with the aria-live="assertive" and aria-atomic="true" attribute (optional).

role="status" is suitable for reporting less important errors and warnings. For example, an autosave message, an incorrectly filled field, and the like. This role should be combined with the aria-live="polite" attribute for compatibility.

If you need to make message history, error list and anything where the sequence of information updates is important, use role="log". For greater compatibility, use the aria-live="polite" attribute along with it.

When you have tickers, currency rates or any other element on your page where information changes quickly, then set role="marquee" for them. For compatibility, supplement it with aria-live="off".

For a timer, counter or stopwatch set role="timer". Don't forget aria-live="off" for better compatibility.

aria-live="" is responsible for how urgently changes need to be announced. Where changes don't need to be announced, use aria-live="off". In most cases there's no urgency to announce changes, so aria-live="polite" comes in handy. Sometimes, when it's an important message, such as a server error, you can use aria-live="assertive".

aria-atomic="" is an optional attribute. It affects whether a screen reader announces a context or only announces changes. By default, all elements are set to aria-atomic="false", meaning screen readers only report content changes. If you change it to aria-atomic="true", screen readers will read out the whole thing, including the unchanged part. In most cases, there's no need to change the default behaviour.

Another optional attribute is aria-relevant="". It is needed to define the type of content changes. It has several values, which can be listed with a space. There are few real-world usage scenarios (deleting or adding a friend to your friend list), and many A screen readers ignore it.

The last optional attribute is aria-busy="". Tells assistive technologies whether the element's content is currently being updated or not. By default, elements are set to aria-busy="false". Screen readers announce changes without waiting for them to complete. In some cases, you can use aria-busy="true" when you want to wait for all updates. May be useful for sports statistics or a text document in group edit mode.

Further reading

Other articles

\ No newline at end of file diff --git a/en/articles/css-media-features-for-a11y/index.html b/en/articles/css-media-features-for-a11y/index.html index e36772c..80ea707 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
Published —

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
 Published — 
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;
   }
@@ -37,4 +37,4 @@
   .parallax-scrolling-image {
 	position: relative;
   }
-}
Animation can also be an important part of a website. Therefore, it is better to build off the content. You can always slow down animations so that they are not dangerous for users or distracting.
I wrote more about this media feature and animation requirements in post about accessibility for people with vestibular disorders and epileptic seizures.
Preference-reduced-motion testing
A quick test can be done in the browser inspector on Chromium. Go to More tools, select the Rendering tab and turn on Emulate CSS media feature CSS prefers-reduce-motion.
You can also change the animation settings manually.
  • Windows 10: Settings → Ease of Access → Display → Show animations in Windows.
  • Windows 11: Settings → Accessibility → Visual effects → Animation effects.
  • macOS: System Preferences → Accessibility → Display → Reduce Motion.
  • iOS: Settings → Accessibility → Motion → Reduce Motion.
  • Android: Settings → Accessibility → Display → Remove animations.
Other articles
© Tatiana Fokina, 2021–2024 Icons are from Iconfinder. Build on 11ty. Find an issue? Let me know on GitHub

\ No newline at end of file
+}

Animation can also be an important part of a website. Therefore, it is better to build off the content. You can always slow down animations so that they are not dangerous for users or distracting.

I wrote more about this media feature and animation requirements in post about accessibility for people with vestibular disorders and epileptic seizures.

Preference-reduced-motion testing

A quick test can be done in the browser inspector on Chromium. Go to More tools, select the Rendering tab and turn on Emulate CSS media feature CSS prefers-reduce-motion.

You can also change the animation settings manually.

  • Windows 10: Settings → Ease of Access → Display → Show animations in Windows.
  • Windows 11: Settings → Accessibility → Visual effects → Animation effects.
  • macOS: System Preferences → Accessibility → Display → Reduce Motion.
  • iOS: Settings → Accessibility → Motion → Reduce Motion.
  • Android: Settings → Accessibility → Display → Remove animations.

Other articles

\ No newline at end of file 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 4d5a495..035e07a 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
Published —

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
 Published — 
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 {
@@ -38,7 +38,7 @@
         animation-iteration-count: 1 !important;
         transition-duration: 0.001ms !important;
     }
-}
An update media feature from the Media Queries Level 4 specification, which is now in candidate recommendation status. update determines whether the output device can change an appearance of content once it has been rendered. There are three values: none, slow and fast.
The snippet below uses low. It is suitable for situations where the layout changes dynamically according to normal CSS rules, but the device doesn't display the changes smoothly. For example, e-ink screens or cheap smartphones.
Option 3, which has everything:
:root {
+}
An update media feature from the Media Queries Level 4 specification, which is now in candidate recommendation status. update determines whether the output device can change an appearance of content once it has been rendered. There are three values: none, slow and fast.
The snippet below uses low. It is suitable for situations where the layout changes dynamically according to normal CSS rules, but the device doesn't display the changes smoothly. For example, e-ink screens or cheap smartphones.
Option 3, which has everything:
:root {
     --animation-duration: 250ms;
     --transition-duration: 250ms;
 }
@@ -77,4 +77,4 @@
         transition-duration: 0s !important;
         transition-delay: 0s !important;
     }
-}
 If possible, add alternative styles without animation and dangerous images or give a link to a text version from pages with parallax.
 Not all users are advanced and know where the animation settings are. If you consider the human factor, you can add a special button in the menu. It will enable safer animations. This is what they did on an Animal Crossing website.
 It should be possible to pause, stop or generally hide any information that:
  • automatically scrolls, moves, and blinks;
  • refreshes for more than 5 seconds;
  • displayed in parallel with other content.
For example, parallax effects or carousels. Usually, pause and stop buttons handle this.
Automatic video playback can be stopped by removing autoplay in <video controls>. Sound can be muted with the muted attribute.
For all animated elements, you can set animation-play-state: paused;. This will pause an animation by default.
This requirement does not apply to loading animations. Users might think the loading is paused or cancelled. The same goes for ads, as they are sometimes necessary for accessing content. Hello, YouTube.
 Set a short animation-duration and transition-duration instead of animation: none or transition: none.
 GIFs cause the most trouble. Users cannot control their speed or turn them off.
A good option is to replace GIFs with videos using the loop attribute or with SVG animation. Use scripts to add control elements for them. For example, gifplayer on jQuery. Or you can add the web component <x-gif>.
 Animated text is also not the most harmless part of the interface. There are no standard ways to adjust its animation yet. If it moves significantly to the side or noticeably increases/decreases in size, it can also cause seizures or dizziness. So, it's better to either completely abandon this idea or change the content slightly and smoothly.
 Place a warning about dangerous content if you're unsure and can't do anything else.
 Follow a couple of simple recommendations about patterns and images. If they consist of straight contrasting lines, it's better to stop at 8. If they are waves, then place no more than 5 next to each other.
What to refer to in WCAG 2.1
Accessibility criteria for people with epileptic seizures and vestibular impairment are collected in two guidelines:
Making an interface safe is not that hard, but very important. When people with epilepsy or vestibular impairment visit a website, it's not just about being able to read a text. An inaccessible interface can make them feel worse and sometimes pose a threat to life.
Vestibular impairment can appear spontaneously. For example, due to side effects from medications, head injuries, and even hot weather. The same situation applies to epileptic seizures. We are somewhat prepared for users with screen readers, but we cannot predict what will make a person feel unwell. Therefore, it is so important not to create barriers from the start.
Further reading
Other articles
© Tatiana Fokina, 2021–2024 Icons are from Iconfinder. Build on 11ty. Find an issue? Let me know on GitHub

\ No newline at end of file
+}

If possible, add alternative styles without animation and dangerous images or give a link to a text version from pages with parallax.

Not all users are advanced and know where the animation settings are. If you consider the human factor, you can add a special button in the menu. It will enable safer animations. This is what they did on an Animal Crossing website.

It should be possible to pause, stop or generally hide any information that:

  • automatically scrolls, moves, and blinks;
  • refreshes for more than 5 seconds;
  • displayed in parallel with other content.

For example, parallax effects or carousels. Usually, pause and stop buttons handle this.

Automatic video playback can be stopped by removing autoplay in <video controls>. Sound can be muted with the muted attribute.

For all animated elements, you can set animation-play-state: paused;. This will pause an animation by default.

This requirement does not apply to loading animations. Users might think the loading is paused or cancelled. The same goes for ads, as they are sometimes necessary for accessing content. Hello, YouTube.

Set a short animation-duration and transition-duration instead of animation: none or transition: none.

GIFs cause the most trouble. Users cannot control their speed or turn them off.

A good option is to replace GIFs with videos using the loop attribute or with SVG animation. Use scripts to add control elements for them. For example, gifplayer on jQuery. Or you can add the web component <x-gif>.

Animated text is also not the most harmless part of the interface. There are no standard ways to adjust its animation yet. If it moves significantly to the side or noticeably increases/decreases in size, it can also cause seizures or dizziness. So, it's better to either completely abandon this idea or change the content slightly and smoothly.

Place a warning about dangerous content if you're unsure and can't do anything else.

Follow a couple of simple recommendations about patterns and images. If they consist of straight contrasting lines, it's better to stop at 8. If they are waves, then place no more than 5 next to each other.

What to refer to in WCAG 2.1

Accessibility criteria for people with epileptic seizures and vestibular impairment are collected in two guidelines:

Making an interface safe is not that hard, but very important. When people with epilepsy or vestibular impairment visit a website, it's not just about being able to read a text. An inaccessible interface can make them feel worse and sometimes pose a threat to life.

Vestibular impairment can appear spontaneously. For example, due to side effects from medications, head injuries, and even hot weather. The same situation applies to epileptic seizures. We are somewhat prepared for users with screen readers, but we cannot predict what will make a person feel unwell. Therefore, it is so important not to create barriers from the start.

Further reading

Other articles

\ No newline at end of file diff --git a/en/articles/index.html b/en/articles/index.html index fa5e98c..94631ad 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 link

How to skip large navigation with skip link, who needs it and what are the approaches to implementing skip content pattern.

  • Patterns
  • HTML
  • CSS
\ 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 link

How to skip large navigation with skip link, who needs it and what are the approaches to implementing skip content pattern.

\ 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 244f9fb..9e90689 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-05-05T00:00:00.000Z" - }

Understanding skip link

  • Patterns
  • HTML
  • CSS
Published —

There are many small but useful patterns available on the web. One of them is the content skip link or skip link. This is a hyperlink that leads to the main content of the 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 bulky complex table, letter indexes, and lists with chapters or technical specifications. Most often skip link is useful for skipping site navigation in the header.

Exceptions are the menu in the footer and small navigation in the header, which consists of a couple of links and a logo. In the case of the footer, you can return to the top of the page using keys, gestures and other in-built browser' features. And the small navigation won't take up much time for users.

In theory, everything is simple, but in practice, it is a bit more complicated. Let's try to deal with everything in order.

Theory

What WCAG 2.1 says about this.

In the accessibility guidelines, there are two criterions related to skip links. The first deals with them indirectly and the second directly.

  • 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:

  • landmark navigation (landmarks);
  • skip link.

The first method is available for screen reader users. Landmarks are added using semantic tags or thanks to ARIA. The second mechanic has a larger audience. It is not only users with visual impairments.

You can meet the advice that skip link is not needed on a site with a good semantic layout. This is not quite true. Not all screen reader users know about shortcuts to open a menu with landmarks, and other keyboard users don't have this option. Also, the more navigation options, the better.

Who needs a skip link

In short, anyone who consistently navigates pages and can't skip content quickly. In a nutshell, four categories of users. These are:

  • Screen reader users, who navigate desktop sites with a keyboard and mobile sites with taps and swipes.
  • Users with motor impairments who use a keyboard, remote computer buttons, and other switches.
  • Any other keyboard users. They may be advanced level or have a temporarily broken mouse.
  • Screen magnifier users who use the keyboard to navigate.

Imagine that you are using a keyboard for navigation and you have entered the site of an online shop, for example, Ozon. You found the product you wanted, navigated to it and found yourself back at the beginning of the page. About 40 tabs and finally you can find out more about your favourite backpack. With skip link you would be in the right place in one click and not fall asleep on the way.

Requirements for skip link

  • Located in the first place in tab order.
  • Leads directly to the main content and sets the focus on it. It is more effective if the page has one main area, <main>.
  • It can be located in the main area of the page. In this case, it skips the necessary block and leads to the beginning of the next.
  • It has a clear name and a good description of where it leads.
  • It can be always visible, or it can appear at the keyboard focus. In both cases, it meets WCAG criteria.
  • You can add more than one of these links. For example, one leads to the main content, and the second - to the search bar. You should not overdo the number, otherwise there is no point in links.
  • Should not interfere with the 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 the pattern, and they don't need another way to scroll to the main content.

Practice

A project should already support keyboard focus and use a semantic layout. Without this, skip link is useless.

Marking up the page

Before we move on to markup, a couple of words about the link text. On English websites, "Skip to main content" or "Skip to content" is most often used.

A few more variations on the title:

  • Skip navigation;
  • Skip main navigation;
  • Skip navigation links.

Now let's talk about markup.

The practical implementation of skip link is an anchor link. It is better to add it to the beginning of <body> or <header> if it is the first element on the page. In the examples, I will add it to the beginning of the header.

<header>
+		}
 
Understanding skip link
  • Patterns
  • HTML
  • CSS
 Published — 
There are many small but useful patterns available on the web. One of them is the content skip link or skip link. This is a hyperlink that leads to the main content of the 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 bulky complex table, letter indexes, and lists with chapters or technical specifications. Most often skip link is useful for skipping site navigation in the header.
Exceptions are the menu in the footer and small navigation in the header, which consists of a couple of links and a logo. In the case of the footer, you can return to the top of the page using keys, gestures and other in-built browser' features. And the small navigation won't take up much time for users.
In theory, everything is simple, but in practice, it is a bit more complicated. Let's try to deal with everything in order.
Theory
What WCAG 2.1 says about this.
In the accessibility guidelines, there are two criterions related to skip links. The first deals with them indirectly and the second directly.
  • 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:
  • landmark navigation (landmarks);
  • skip link.
The first method is available for screen reader users. Landmarks are added using semantic tags or thanks to ARIA. The second mechanic has a larger audience. It is not only users with visual impairments.
You can meet the advice that skip link is not needed on a site with a good semantic layout. This is not quite true. Not all screen reader users know about shortcuts to open a menu with landmarks, and other keyboard users don't have this option. Also, the more navigation options, the better.
Who needs a skip link
In short, anyone who consistently navigates pages and can't skip content quickly. In a nutshell, four categories of users. These are:
  • Screen reader users, who navigate desktop sites with a keyboard and mobile sites with taps and swipes.
  • Users with motor impairments who use a keyboard, remote computer buttons, and other switches.
  • Any other keyboard users. They may be advanced level or have a temporarily broken mouse.
  • Screen magnifier users who use the keyboard to navigate.
Imagine that you are using a keyboard for navigation and you have entered the site of an online shop, for example, Ozon. You found the product you wanted, navigated to it and found yourself back at the beginning of the page. About 40 tabs and finally you can find out more about your favourite backpack. With skip link you would be in the right place in one click and not fall asleep on the way.
Requirements for skip link
  • Located in the first place in tab order.
  • Leads directly to the main content and sets the focus on it. It is more effective if the page has one main area, <main>.
  • It can be located in the main area of the page. In this case, it skips the necessary block and leads to the beginning of the next.
  • It has a clear name and a good description of where it leads.
  • It can be always visible, or it can appear at the keyboard focus. In both cases, it meets WCAG criteria.
  • You can add more than one of these links. For example, one leads to the main content, and the second - to the search bar. You should not overdo the number, otherwise there is no point in links.
  • Should not interfere with the 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 the pattern, and they don't need another way to scroll to the main content.
Practice
A project should already support keyboard focus and use a semantic layout. Without this, skip link is useless.
Marking up the page
Before we move on to markup, a couple of words about the link text. On English websites, "Skip to main content" or "Skip to content" is most often used.
A few more variations on the title:
  • Skip navigation;
  • Skip main navigation;
  • Skip navigation links.
Now let's talk about markup.
The practical implementation of skip link is an anchor link. It is better to add it to the beginning of <body> or <header> if it is the first element on the page. In the examples, I will add it to the beginning of the header.
<header>
     <a href="#main-content" class="skip-link">Skip to main content</a>
      <!-- Enormous navigation -->
 </header>
But where it should lead is the main sticking point. There are several answers to that question.
Option 1, the classic one. The link leads directly to <main>.
``html
       
   
```
This option works more or less well in modern browsers, but there is one "but". There may be problems in all mobile browsers on older versions of iOS and Android, in older Chrome and even in Safari 14. Every place has its bugs.
  • iOS + VoiceOver.
    When skip linking, scrolling is visually triggered, but after swiping, the focus moves to a different area rather than the content of the main block. Another bug returns to the beginning of the page when you try to go to the next item in the main block.
  • Android + TalkBack. Hidden links just don't get focus. This is a system-wide bug that causes the focus event to not fire on such items.
  • Chrome. Focus stays on the skip link and moves to the next element after the link after clicking on Tab.
The bug on iOS was fixed in April 2020, on Android in February 2021 and in Chrome back in 2017. Hence, they don't occur with iOS 13+, at least not with Android 10+ and in older versions of Chrome. However, a part of screen reader users don't update browsers and operating systems for a long time, so fixing bugs doesn't make it any better.
Option 2, where the link leads to <h1> inside <main>.
<!-- Option 2 -->
@@ -137,4 +137,4 @@
 /* Show on focus */
 .skip-link:focus {
     transform: translateY(0%);
-}
Putting the final touches
The rest of skip link styling depends on your design vision. The most important thing is that it should be clearly visible when on keyboard focus.
WebAIM recommends not to show the link unexpectedly. This can confuse keyboard users who are seeing the interface. A smooth animation will fix this. Then the link will move out from behind the edge of the screen and move back in when there's no longer focus on it.
You can place the links in any top part of the screen. They are often placed in the top left corner, but this isn't an ironclad rule.
I've put together a small list of sites with skip link where you can see how it works and looks. Use Tab for navigation on Windows and Tab or Option+Tab on macOS.
A few last words
Often the simpler something seems, the more complicated it is in reality. This happened with skip link.
There are quite a few ways to make a skip link for such a small element. They have pros and cons. I would go for the classic implementation with the link that leads to <main> or <h1> with tabindex="-1" from the third option. As for styles for hiding the link, all the options are good. You can choose whichever one suits the project best. I mostly use absolute positioning and negative left value.
Further reading
Thanks to Vasily Dudin for help with editing.
Other articles
© Tatiana Fokina, 2021–2024 Icons are from Iconfinder. Build on 11ty. Find an issue? Let me know on GitHub

\ No newline at end of file
+}

Putting the final touches

The rest of skip link styling depends on your design vision. The most important thing is that it should be clearly visible when on keyboard focus.

WebAIM recommends not to show the link unexpectedly. This can confuse keyboard users who are seeing the interface. A smooth animation will fix this. Then the link will move out from behind the edge of the screen and move back in when there's no longer focus on it.

You can place the links in any top part of the screen. They are often placed in the top left corner, but this isn't an ironclad rule.

I've put together a small list of sites with skip link where you can see how it works and looks. Use Tab for navigation on Windows and Tab or Option+Tab on macOS.

A few last words

Often the simpler something seems, the more complicated it is in reality. This happened with skip link.

There are quite a few ways to make a skip link for such a small element. They have pros and cons. I would go for the classic implementation with the link that leads to <main> or <h1> with tabindex="-1" from the third option. As for styles for hiding the link, all the options are good. You can choose whichever one suits the project best. I mostly use absolute positioning and negative left value.

Further reading

Thanks to Vasily Dudin for help with editing.

Other articles

\ No newline at end of file diff --git a/en/index.html b/en/index.html index b7a710c..419758e 100644 --- a/en/index.html +++ b/en/index.html @@ -1 +1 @@ -Blog on Digital Accessibility

About a blog

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).

I write and translate articles, and I am also an editor of the “Accessibility” section in Doka Guide, a Russian language community-driven documentation. Now, I have a new role — one of the hosts of the first Russian-speaking podcast about accessibility and inclusion, Inclusive Pineapple (because why not?). A long time ago, I even organized St. Petersburg pitera11y_meetup.

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.

Latest 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
\ No newline at end of file +Blog on Digital Accessibility

About a blog

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).

I write and translate articles, and I am also an editor of the “Accessibility” section in Doka Guide, a Russian language community-driven documentation. Now, I have a new role — one of the hosts of the first Russian-speaking podcast about accessibility and inclusion, Inclusive Pineapple (because why not?). A long time ago, I even organized St. Petersburg pitera11y_meetup.

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.

Latest 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
\ No newline at end of file diff --git a/ru/404/index.html b/ru/404/index.html index f8353a9..2ca2637 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

\ 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

\ 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 9e5034b..7a80900 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"
@@ -45,4 +45,4 @@
   tabindex="1"
 >
   Что-то преступное
-</div>
  • NVDA и Chrome: ничего не объявляет.
  • NVDA и Firefox: ничего не объявляет.
  • VoiceOver и Safari: «Это не кнопка». Объявляет только содержимое атрибута aria-label.
В Chrome для <div> c role="tapir opossum" вычислена роль generic, в Firefox — text leaf, а в Safari просто не нашлось подходящей роли.
generic — это встроенная роль <div>. Это значит, что перед нами безымянный элемент-контейнер без семантического значения. А text leaf означает какой-то текстовый контент. Как думаете, что стало с именем элемента? Правильно, оно не изменилось и берётся из aria-label.
Элемент с двумя выдуманными ролями в превью доступного дерева из трёх браузеров.
Вывод: если оба значения невалидные, то в дерево доступности или попадает встроенная роль элемента, или ничего не вычисляется. Зависит от браузера.
Финальные мысли
Всё это время WAI-ARIA предусматривала возможность задавать для атрибута role больше одного значения, но не особо это афишировала.
Не думаю, что это ужасное упущение в спецификации. Сложно представить, для каких ролей нужны фолбеки в современных браузерах. К тому же, с атрибутом role и так легко запутаться. Когда у тебя есть возможность задать бесконечное количество ролей, то это ещё больше усложняет разметку и может привести к неожиданным ошибкам.
Что почитать
Тысяча благодарностей Василию Дудину за помощь с редактированием ❤️
Другие статьи
© Татьяна Фокина, 2021–2024 Иконки с Iconfinder. Разработано на 11ty. Нашли ошибку? Расскажите мне на GitHub

\ No newline at end of file
+</div>
  • NVDA и Chrome: ничего не объявляет.
  • NVDA и Firefox: ничего не объявляет.
  • VoiceOver и Safari: «Это не кнопка». Объявляет только содержимое атрибута aria-label.

В Chrome для <div> c role="tapir opossum" вычислена роль generic, в Firefox — text leaf, а в Safari просто не нашлось подходящей роли.

generic — это встроенная роль <div>. Это значит, что перед нами безымянный элемент-контейнер без семантического значения. А text leaf означает какой-то текстовый контент. Как думаете, что стало с именем элемента? Правильно, оно не изменилось и берётся из aria-label.

Элемент с двумя выдуманными ролями в превью доступного дерева из трёх браузеров.

Вывод: если оба значения невалидные, то в дерево доступности или попадает встроенная роль элемента, или ничего не вычисляется. Зависит от браузера.

Финальные мысли

Всё это время WAI-ARIA предусматривала возможность задавать для атрибута role больше одного значения, но не особо это афишировала.

Не думаю, что это ужасное упущение в спецификации. Сложно представить, для каких ролей нужны фолбеки в современных браузерах. К тому же, с атрибутом role и так легко запутаться. Когда у тебя есть возможность задать бесконечное количество ролей, то это ещё больше усложняет разметку и может привести к неожиданным ошибкам.

Что почитать

Тысяча благодарностей Василию Дудину за помощь с редактированием ❤️

Другие статьи

\ No newline at end of file diff --git a/ru/articles/css-media-features-for-a11y/index.html b/ru/articles/css-media-features-for-a11y/index.html index 8c9b423..2049c91 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;
   }
@@ -37,7 +37,7 @@
   .parallax-scrolling-image {
     position: relative;
   }
-}
Анимация может быть и важной частью сайта. Поэтому лучше отталкиваться от контента. Всегда можно замедлить анимацию так, чтобы она не была опасна для пользователей или не отвлекала их.
Про эту мадиафичу и требования к анимации подробнее писала в посте про доступность для людей с вестибулярными нарушениями и эпилептическими приступами.
Тестирование prefers-reduced-motion
Быстро протестировать можно в инспекторе браузеров на Chromium. Зайдите в «Другие инструменты» (More tools), выберите вкладку «Отрисовка» (Rendering) и включите «Эмулировать медиафункцию CSS prefers-reduce-motion» (Emulate CSS media feature prefers-reduce-motion).
Изменить настройки анимации можно также вручную.
  • Windows 10: Настройки (Settings) → Специальные возможности (Ease of Access) → Экран (Display) → Показывать анимацию в Windows (Show animations in Windows).
  • Windows 11: Настройки (Settings) → Специальные возможности (Accessibility) → Визуальные эффекты (Visual effects) → Эффекты анимации (Animation effects).
  • macOS: Системные настройки (System Preferences) → Универсальный доступ (Accessibility) → Монитор (Display) → Уменьшить движение (Reduce Motion).
  • iOS: Настройки (Settings) → Универсальный доступ (Accessibility) → Движение (Motion) → Уменьшение движения (Reduce Motion).
  • Android: Настройки (Settings) → Специальные возможности (Accessibility) → Экран (Display) → Удалить анимации (Remove animations).
prefers-color-scheme
Определяет выбранную цветовую схему.
Доступные значения:
  • light, для светлой схемы.
  • dark, для тёмной схемы.
У prefers-color-scheme высокая глобальная поддержка — 91.68 %.
Разработчики могут управлять всеми стилями при работе с тёмными темами сайта. Особенно важно обратить внимание на цвета:
  • фонов,
  • текстов,
  • интерактивных элементов в разных состояниях,
  • иконок и изображений,
  • других декоративных элементов.
Например, картинки в тёмной теме можно сделать не такими контрастными с помощью filter, а ещё поменять значения background-color и color.
.body {
+}
Анимация может быть и важной частью сайта. Поэтому лучше отталкиваться от контента. Всегда можно замедлить анимацию так, чтобы она не была опасна для пользователей или не отвлекала их.
Про эту мадиафичу и требования к анимации подробнее писала в посте про доступность для людей с вестибулярными нарушениями и эпилептическими приступами.
Тестирование prefers-reduced-motion
Быстро протестировать можно в инспекторе браузеров на Chromium. Зайдите в «Другие инструменты» (More tools), выберите вкладку «Отрисовка» (Rendering) и включите «Эмулировать медиафункцию CSS prefers-reduce-motion» (Emulate CSS media feature prefers-reduce-motion).
Изменить настройки анимации можно также вручную.
  • Windows 10: Настройки (Settings) → Специальные возможности (Ease of Access) → Экран (Display) → Показывать анимацию в Windows (Show animations in Windows).
  • Windows 11: Настройки (Settings) → Специальные возможности (Accessibility) → Визуальные эффекты (Visual effects) → Эффекты анимации (Animation effects).
  • macOS: Системные настройки (System Preferences) → Универсальный доступ (Accessibility) → Монитор (Display) → Уменьшить движение (Reduce Motion).
  • iOS: Настройки (Settings) → Универсальный доступ (Accessibility) → Движение (Motion) → Уменьшение движения (Reduce Motion).
  • Android: Настройки (Settings) → Специальные возможности (Accessibility) → Экран (Display) → Удалить анимации (Remove animations).
prefers-color-scheme
Определяет выбранную цветовую схему.
Доступные значения:
  • light, для светлой схемы.
  • dark, для тёмной схемы.
У prefers-color-scheme высокая глобальная поддержка — 91.68 %.
Разработчики могут управлять всеми стилями при работе с тёмными темами сайта. Особенно важно обратить внимание на цвета:
  • фонов,
  • текстов,
  • интерактивных элементов в разных состояниях,
  • иконок и изображений,
  • других декоративных элементов.
Например, картинки в тёмной теме можно сделать не такими контрастными с помощью filter, а ещё поменять значения background-color и color.
.body {
   color: black;
   background-color: white;
 }
@@ -116,4 +116,4 @@
   .transparency-bg {
     opacity: 1;
   }
-}
О чём не рассказала
В этом посте не разбирала только одну медиафичу для пользовательских настроек — prefers-reduced-data. Она нужна для отслеживания настроек объёма получения данных.
Связана с перфомансом и тоже пригодится для доступности. Больше подробностей в «Creating websites with prefers-reduced-data».
Выводы
CSS-медиафичи дают нам возможность учитывать на сайтах пользовательские настройки. С их помощью можно в несколько строк кода улучшить пользовательский опыт и сделать интерфейс доступнее и безопаснее.
Уже сейчас можно смело использовать prefers-reduced-motion и prefers-color-scheme. Пока не так хорошо поддерживаются forced-colors, inverted-colors и prefers-contrast, но их поддержка постепенно расширяется. У prefers-reduced-transparency, скорее всего, всё ещё впереди. А ms-high-contrast устарела, так лучше не задавать стили для режима высокой контрастности в современных браузерах.
Что почитать и посмотреть
И снова спасибо Василию Дудину за помощь с редактированием.
Другие статьи
© Татьяна Фокина, 2021–2024 Иконки с Iconfinder. Разработано на 11ty. Нашли ошибку? Расскажите мне на GitHub

\ No newline at end of file
+}

О чём не рассказала

В этом посте не разбирала только одну медиафичу для пользовательских настроек — prefers-reduced-data. Она нужна для отслеживания настроек объёма получения данных.

Связана с перфомансом и тоже пригодится для доступности. Больше подробностей в «Creating websites with prefers-reduced-data».

Выводы

CSS-медиафичи дают нам возможность учитывать на сайтах пользовательские настройки. С их помощью можно в несколько строк кода улучшить пользовательский опыт и сделать интерфейс доступнее и безопаснее.

Уже сейчас можно смело использовать prefers-reduced-motion и prefers-color-scheme. Пока не так хорошо поддерживаются forced-colors, inverted-colors и prefers-contrast, но их поддержка постепенно расширяется. У prefers-reduced-transparency, скорее всего, всё ещё впереди. А ms-high-contrast устарела, так лучше не задавать стили для режима высокой контрастности в современных браузерах.

Что почитать и посмотреть

И снова спасибо Василию Дудину за помощь с редактированием.

Другие статьи

\ No newline at end of file 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 f65075c..c40c209 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 {
@@ -38,7 +38,7 @@
         animation-iteration-count: 1 !important;
         transition-duration: 0.001ms !important;
     }
-}
Медиафича update из спецификации Media Queries Level 4, которая сейчас в статусе кандидата в рекомендации. update определяет может ли устройство вывода изменить внешний вид контента, как только он отрендерился. Есть три значения: none, slow и fast.
В сниппете используется slow. Оно подходит для ситуаций, когда раскладка динамически изменяется в соответствии с обычными CSS-правилами, но устройство не отображает изменения плавно. Например, экраны с электронными чернилами или дешёвые смартфоны.
Вариант 3, в котором есть всё:
:root {
+}
Медиафича update из спецификации Media Queries Level 4, которая сейчас в статусе кандидата в рекомендации. update определяет может ли устройство вывода изменить внешний вид контента, как только он отрендерился. Есть три значения: none, slow и fast.
В сниппете используется slow. Оно подходит для ситуаций, когда раскладка динамически изменяется в соответствии с обычными CSS-правилами, но устройство не отображает изменения плавно. Например, экраны с электронными чернилами или дешёвые смартфоны.
Вариант 3, в котором есть всё:
:root {
     --animation-duration: 250ms;
     --transition-duration: 250ms;
 }
@@ -77,4 +77,4 @@
         transition-duration: 0s !important;
         transition-delay: 0s !important;
     }
-}
 Если есть возможность, то добавьте альтернативные стили без анимации и опасных картинок или дайте ссылку на текстовую версию со страниц с параллаксом.
 Не все пользователи продвинутые и знают, где находятся настройки анимации. Если учитываете человеческий фактор, то можно добавить специальную кнопку в меню. Она будет включать более безопасную анимацию. Так поступили на сайте Animal Crossing.
 Должна быть возможность поставить на паузу, остановить или вообще скрыть любую информацию, которая:
  • автоматические скроллится, двигается и мигает;
  • обновляется больше 5 секунд;
  • отображается параллельно с другим контентом.
Например, параллакс-эффекты или карусели. Обычно с этим справляются кнопки паузы и остановки.
Автоматическое воспроизведение видео можно отменить, если удалить autoplay в <video controls>. Звук можно убрать атрибутом muted.
Для всех элементов с анимацией можно задать animation-play-state: paused;. Тогда она будет поставлена на паузу по умолчанию.
На анимацию во время загрузки это требование не распространяется. Пользователь может подумать, что загрузка на паузе или вообще отменена. Это же касается рекламы, так как периодически она необходимая часть функционала для доступа к контенту. Привет, YouTube.
 Устанавливайте короткую продолжительность animation-duration и transition-duration вместо animation: none или transition: none.
 Больше всего неприятностей доставляют гифки. Пользователи не могут управлять их скоростью или отключать.
Хороший вариант заменить гифки на видео с атрибутом loop или на SVG-анимацию. Используйте скрипты, чтобы добавить для них элементы управления. Например, gifplayer на jQuery. А можно добавить веб-компонент <x-gif>.
 Анимированный текст также не самая безобидная часть интерфейса. Пока нет стандартных возможностей настроить его анимацию. Если он сильно смещается в сторону или ощутимо увеличивается/уменьшается, то это тоже может вызвать приступ или головокружение. Так что лучше либо совсем отказаться от этой идеи, либо изменять контент незначительно и плавно.
 Разместите предупреждение об опасном контенте, если сомневаетесь и не можете больше ничего сделать.
 Следуйте паре простых рекомендаций о паттернах и картинках. Если они состоят из прямых контрастных линий, то лучше остановиться на 8. Если это волны, то размещайте рядом не больше 5.
На что ссылаться в WCAG 2.1
Критерии доступности для людей с эпилептическими приступами и вестибулярными нарушениями собраны в двух руководствах:
Сделать интерфейс безопасным не так сложно, но очень важно. Когда на сайт заходят люди с эпилепсией или вестибулярными нарушениями, то речь идёт не только о возможности прочитать текст. Недоступный интерфейс может ухудшить их самочувствие и иногда стать угрозой для жизни.
Вестибулярные нарушения могут появляться спонтанно. Например, из-за побочных эффектов от лекарств, травм головы и даже жаркой погоды. Такая же ситуация с эпилептическими приступами. Мы более-менее готовы к пользователям со скринридерами, но не можем предсказать от чего человеку станет плохо. Поэтому так важно с самого начала не создавать барьеры.
Полезные ссылки
Другие статьи
© Татьяна Фокина, 2021–2024 Иконки с Iconfinder. Разработано на 11ty. Нашли ошибку? Расскажите мне на GitHub

\ No newline at end of file
+}

Если есть возможность, то добавьте альтернативные стили без анимации и опасных картинок или дайте ссылку на текстовую версию со страниц с параллаксом.

Не все пользователи продвинутые и знают, где находятся настройки анимации. Если учитываете человеческий фактор, то можно добавить специальную кнопку в меню. Она будет включать более безопасную анимацию. Так поступили на сайте Animal Crossing.

Должна быть возможность поставить на паузу, остановить или вообще скрыть любую информацию, которая:

  • автоматические скроллится, двигается и мигает;
  • обновляется больше 5 секунд;
  • отображается параллельно с другим контентом.

Например, параллакс-эффекты или карусели. Обычно с этим справляются кнопки паузы и остановки.

Автоматическое воспроизведение видео можно отменить, если удалить autoplay в <video controls>. Звук можно убрать атрибутом muted.

Для всех элементов с анимацией можно задать animation-play-state: paused;. Тогда она будет поставлена на паузу по умолчанию.

На анимацию во время загрузки это требование не распространяется. Пользователь может подумать, что загрузка на паузе или вообще отменена. Это же касается рекламы, так как периодически она необходимая часть функционала для доступа к контенту. Привет, YouTube.

Устанавливайте короткую продолжительность animation-duration и transition-duration вместо animation: none или transition: none.

Больше всего неприятностей доставляют гифки. Пользователи не могут управлять их скоростью или отключать.

Хороший вариант заменить гифки на видео с атрибутом loop или на SVG-анимацию. Используйте скрипты, чтобы добавить для них элементы управления. Например, gifplayer на jQuery. А можно добавить веб-компонент <x-gif>.

Анимированный текст также не самая безобидная часть интерфейса. Пока нет стандартных возможностей настроить его анимацию. Если он сильно смещается в сторону или ощутимо увеличивается/уменьшается, то это тоже может вызвать приступ или головокружение. Так что лучше либо совсем отказаться от этой идеи, либо изменять контент незначительно и плавно.

Разместите предупреждение об опасном контенте, если сомневаетесь и не можете больше ничего сделать.

Следуйте паре простых рекомендаций о паттернах и картинках. Если они состоят из прямых контрастных линий, то лучше остановиться на 8. Если это волны, то размещайте рядом не больше 5.

На что ссылаться в WCAG 2.1

Критерии доступности для людей с эпилептическими приступами и вестибулярными нарушениями собраны в двух руководствах:

Сделать интерфейс безопасным не так сложно, но очень важно. Когда на сайт заходят люди с эпилепсией или вестибулярными нарушениями, то речь идёт не только о возможности прочитать текст. Недоступный интерфейс может ухудшить их самочувствие и иногда стать угрозой для жизни.

Вестибулярные нарушения могут появляться спонтанно. Например, из-за побочных эффектов от лекарств, травм головы и даже жаркой погоды. Такая же ситуация с эпилептическими приступами. Мы более-менее готовы к пользователям со скринридерами, но не можем предсказать от чего человеку станет плохо. Поэтому так важно с самого начала не создавать барьеры.

Полезные ссылки

Другие статьи

\ No newline at end of file diff --git a/ru/articles/index.html b/ru/articles/index.html index 9147e53..1627090 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
\ 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

Как не навредить пользователям с эпилепсией и вестибулярными нарушениями

Что, если пользователя укачивает из-за сайта? А вдруг у него случится эпилептический приступ? Давайте разберёмся с тем, какими должны быть интерфейсы для пользователей с эпилепсией и вестибулярными нарушениями.

\ 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 8e98346..e1571e3 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": "2021-08-23T00:00:00.000Z" - }

Разбираемся со skip link

  • Паттерны
  • HTML
  • CSS
Опубликовано —

В вебе есть много небольших, но полезных доступных паттернов. И один из них — ссылка для пропуска контента или скип линк (skip link). Это гиперссылка, которая ведёт к основному содержанию страницы и помогает пропустить объёмный, часто повторяющийся контент. Её главная цель — экономия времени пользователей.

Какой контент считается объёмным? Навигационное меню с логотипом и кучей ссылок, громоздкая сложная таблица, буквенные указатели, списки с главами или техническими характеристиками. Чаще всего skip link полезна для пропуска навигации по сайту в хедере.

Исключения — меню в футере и небольшая навигация в хедере, которая состоит из пары ссылок и логотипа. В случае футера можно вернуться к началу страницы с помощью клавиш, жестов и других встроенных возможностей браузеров. А небольшая навигация не отнимет много времени у пользователей.

В теории всё просто, но на практике несколько сложнее. Давайте попробуем разобраться со всем по порядку.

Теория

Что говорит про это WCAG 2.1

В руководстве по доступности есть два критерия, связанные со skip link. Первый касается их косвенно, а второй напрямую.

Механизмы для пропуска блоков

Есть два механизма:

  • навигация по ориентирам (landmarks);
  • skip link.

Первый способ доступен для пользователей скринридеров. Ориентиры добавляются с помощью семантических тегов или благодаря ARIA. У второго механизма аудитория больше. Это не только пользователи с особенностями зрения.

Можно встретить совет о том, что skip link не нужна на сайте с хорошей семантической вёрсткой. Это не совсем верно. Не все пользователи скринридеров знают о шорткатах для открытия меню с ориентирами, а у других пользователей клавиатуры такой возможности нет. К тому же, чем больше вариантов навигации, тем лучше.

Кому нужна skip link

Если коротко, то всем, кто последовательно навигируется по страницам и не может быстро пропустить контент. Если развёрнуто, то четырём категориям пользователей. Это:

  • Пользователи скринридеров, которые перемещаются по десктопным сайтам с помощью клавиатуры, а по мобильным — касаниями, тапами и свайпами.
  • Пользователи с моторными нарушениями, которые пользуются клавиатурой, выносными компьютерными кнопками и другими переключателями.
  • Любые другие пользователи клавиатуры. Они могут быть продвинутого уровня или у них временно сломалась мышка.
  • Пользователи экранных луп, которые используют для навигации клавиатуру.

Представьте, что используете для навигации клавиатуру и зашли на сайт интернет-магазина, например, Ozon. Вы нашли нужный товар, перешли к нему и снова оказались в начале страницы. Примерно 40 табов и вот наконец можно узнать больше про понравившийся рюкзак. Со skip link вы бы оказались в нужном месте в одно нажатие и не заснули по пути.

Требования к skip link

  • Находится на первом месте в порядке табуляции.
  • Ведёт сразу к основному контенту и устанавливает фокус на нём. Она эффективнее, если на странице одна основная область — <main>.
  • Может располагаться в основной области страницы. В этом случаем она пропускает нужный блок и ведёт в начало следующего.
  • Понятно называется и хорошо описывает, куда ведёт.
  • Может быть всегда видна, а может появляться при фокусе с клавиатуры. В обоих случаях отвечает критериям WCAG.
  • Можно добавлять несколько таких ссылок. Например, одна ведёт к основному контенту, вторая — к поисковой строке. Не стоит перебарщивать с количеством, иначе в ссылках нет смысла.
  • Не должна мешать пользователям мыши. Это дискуссионное требование, но в нём есть разумное зерно. Если такая ссылка всегда видна, то может запутать пользователей мышки. Они не знакомы с этим паттерном, а ещё один способ прокрутки к основному контенту им не нужен.

Практика

В проекте уже должен поддерживаться фокус с клавиатуры и использоваться семантическая вёрстка. Без этого skip link бесполезна.

Размечаем страницу

Перед тем, как перейти к разметке, пара слов про текст ссылки. На англоязычных сайтах чаще всего используют «Skip to main content» или «Skip to content». Кажется, что самые подходящие эквиваленты в русском — «Перейти к основному контенту» или более краткое «К основному контенту». «Cодержание» — широкое понятие и означает содержимое страницы или оглавление. «Контент» лучше отражает, куда ведёт ссылка.

Ещё несколько вариантов названия:

  • пропустить навигацию (Skip navigation);
  • пропустить основную навигацию (Skip main navigation);
  • пропустить ссылки в навигации (Skip navigation links).

Теперь поговорим о разметке.

Практическая реализация skip link — якорная ссылка. Лучше добавить её в начало <body> или <header>, если это первый элемент на странице. В примерах буду добавлять её в начало хедера.

<header>
+		}
 
Разбираемся со skip link
  • Паттерны
  • HTML
  • CSS
 Опубликовано — 
В вебе есть много небольших, но полезных доступных паттернов. И один из них — ссылка для пропуска контента или скип линк (skip link). Это гиперссылка, которая ведёт к основному содержанию страницы и помогает пропустить объёмный, часто повторяющийся контент. Её главная цель — экономия времени пользователей.
Какой контент считается объёмным? Навигационное меню с логотипом и кучей ссылок, громоздкая сложная таблица, буквенные указатели, списки с главами или техническими характеристиками. Чаще всего skip link полезна для пропуска навигации по сайту в хедере.
Исключения — меню в футере и небольшая навигация в хедере, которая состоит из пары ссылок и логотипа. В случае футера можно вернуться к началу страницы с помощью клавиш, жестов и других встроенных возможностей браузеров. А небольшая навигация не отнимет много времени у пользователей.
В теории всё просто, но на практике несколько сложнее. Давайте попробуем разобраться со всем по порядку.
Теория
Что говорит про это WCAG 2.1
В руководстве по доступности есть два критерия, связанные со skip link. Первый касается их косвенно, а второй напрямую.
Механизмы для пропуска блоков
Есть два механизма:
  • навигация по ориентирам (landmarks);
  • skip link.
Первый способ доступен для пользователей скринридеров. Ориентиры добавляются с помощью семантических тегов или благодаря ARIA. У второго механизма аудитория больше. Это не только пользователи с особенностями зрения.
Можно встретить совет о том, что skip link не нужна на сайте с хорошей семантической вёрсткой. Это не совсем верно. Не все пользователи скринридеров знают о шорткатах для открытия меню с ориентирами, а у других пользователей клавиатуры такой возможности нет. К тому же, чем больше вариантов навигации, тем лучше.
Кому нужна skip link
Если коротко, то всем, кто последовательно навигируется по страницам и не может быстро пропустить контент. Если развёрнуто, то четырём категориям пользователей. Это:
  • Пользователи скринридеров, которые перемещаются по десктопным сайтам с помощью клавиатуры, а по мобильным — касаниями, тапами и свайпами.
  • Пользователи с моторными нарушениями, которые пользуются клавиатурой, выносными компьютерными кнопками и другими переключателями.
  • Любые другие пользователи клавиатуры. Они могут быть продвинутого уровня или у них временно сломалась мышка.
  • Пользователи экранных луп, которые используют для навигации клавиатуру.
Представьте, что используете для навигации клавиатуру и зашли на сайт интернет-магазина, например, Ozon. Вы нашли нужный товар, перешли к нему и снова оказались в начале страницы. Примерно 40 табов и вот наконец можно узнать больше про понравившийся рюкзак. Со skip link вы бы оказались в нужном месте в одно нажатие и не заснули по пути.
Требования к skip link
  • Находится на первом месте в порядке табуляции.
  • Ведёт сразу к основному контенту и устанавливает фокус на нём. Она эффективнее, если на странице одна основная область — <main>.
  • Может располагаться в основной области страницы. В этом случаем она пропускает нужный блок и ведёт в начало следующего.
  • Понятно называется и хорошо описывает, куда ведёт.
  • Может быть всегда видна, а может появляться при фокусе с клавиатуры. В обоих случаях отвечает критериям WCAG.
  • Можно добавлять несколько таких ссылок. Например, одна ведёт к основному контенту, вторая — к поисковой строке. Не стоит перебарщивать с количеством, иначе в ссылках нет смысла.
  • Не должна мешать пользователям мыши. Это дискуссионное требование, но в нём есть разумное зерно. Если такая ссылка всегда видна, то может запутать пользователей мышки. Они не знакомы с этим паттерном, а ещё один способ прокрутки к основному контенту им не нужен.
Практика
В проекте уже должен поддерживаться фокус с клавиатуры и использоваться семантическая вёрстка. Без этого skip link бесполезна.
Размечаем страницу
Перед тем, как перейти к разметке, пара слов про текст ссылки. На англоязычных сайтах чаще всего используют «Skip to main content» или «Skip to content». Кажется, что самые подходящие эквиваленты в русском — «Перейти к основному контенту» или более краткое «К основному контенту». «Cодержание» — широкое понятие и означает содержимое страницы или оглавление. «Контент» лучше отражает, куда ведёт ссылка.
Ещё несколько вариантов названия:
  • пропустить навигацию (Skip navigation);
  • пропустить основную навигацию (Skip main navigation);
  • пропустить ссылки в навигации (Skip navigation links).
Теперь поговорим о разметке.
Практическая реализация skip link — якорная ссылка. Лучше добавить её в начало <body> или <header>, если это первый элемент на странице. В примерах буду добавлять её в начало хедера.
<header>
     <a href="#main-content" class="skip-link">Перейти к основному контенту</a>
     <!-- Внушительная навигация -->
 </header>
А вот куда она должна вести — главная загвоздка. Есть несколько ответов на этот вопрос.
Вариант 1, классический. Ссылка ведёт прямо к <main>.
<!-- Вариант 1 -->
@@ -146,4 +146,4 @@
 /* Показываем при фокусе */
 .skip-link:focus {
     transform: translateY(0%);
-}
Добавляем последние штрихи
Остальная стилизация skip link зависит от вашего дизайнерского видения. Самое главное, чтобы она была хорошо видна при фокусе с клавиатуры.
WebAIM рекомендует не показывать ссылку неожиданно. Это может сбить с толку пользователей клавиатуры, которые видят интерфейс. Это исправит плавная анимация. Тогда ссылка будет выезжать из-за края экрана и уезжать обратно, когда на ней больше нет фокуса.
Размещать ссылки можно в любой верхней части экрана. Очень часто их располагают в левом верхнем углу, но это не железное правило.
Собрала небольшой список сайтов со skip link, где можно посмотреть, как они задизайнены у других. Используйте для навигации Tab на Windows и Tab или Option+Tab на macOS.
Пара слов напоследок
Часто, чем что-то кажется проще, тем оно сложнее на самом деле. Это произошло и со skip link.
Вариантов того, как сделать skip link, довольно много для такого небольшого элемента. У них есть плюсы и минусы. Для себя выбрала бы классическую реализацию со ссылкой, которая ведёт к <main> или <h1> с tabindex="-1" из третьего варианта. И прогрессивно улучшила её с помощью JS. Что касается стилей для скрытия ссылки, то они все рабочие. Можно выбрать любой, который больше подходит для проекта. Я чаще всего пользуюсь абсолютным позиционированием и отрицательным значением left.
Что почитать
Спасибо Василию Дудину за помощь с редактированием.
Другие статьи
© Татьяна Фокина, 2021–2024 Иконки с Iconfinder. Разработано на 11ty. Нашли ошибку? Расскажите мне на GitHub

\ No newline at end of file
+}

Добавляем последние штрихи

Остальная стилизация skip link зависит от вашего дизайнерского видения. Самое главное, чтобы она была хорошо видна при фокусе с клавиатуры.

WebAIM рекомендует не показывать ссылку неожиданно. Это может сбить с толку пользователей клавиатуры, которые видят интерфейс. Это исправит плавная анимация. Тогда ссылка будет выезжать из-за края экрана и уезжать обратно, когда на ней больше нет фокуса.

Размещать ссылки можно в любой верхней части экрана. Очень часто их располагают в левом верхнем углу, но это не железное правило.

Собрала небольшой список сайтов со skip link, где можно посмотреть, как они задизайнены у других. Используйте для навигации Tab на Windows и Tab или Option+Tab на macOS.

Пара слов напоследок

Часто, чем что-то кажется проще, тем оно сложнее на самом деле. Это произошло и со skip link.

Вариантов того, как сделать skip link, довольно много для такого небольшого элемента. У них есть плюсы и минусы. Для себя выбрала бы классическую реализацию со ссылкой, которая ведёт к <main> или <h1> с tabindex="-1" из третьего варианта. И прогрессивно улучшила её с помощью JS. Что касается стилей для скрытия ссылки, то они все рабочие. Можно выбрать любой, который больше подходит для проекта. Я чаще всего пользуюсь абсолютным позиционированием и отрицательным значением left.

Что почитать

Спасибо Василию Дудину за помощь с редактированием.

Другие статьи

\ No newline at end of file diff --git a/ru/articles/wcag-character-key/index.html b/ru/articles/wcag-character-key/index.html index 48f1954..f2e841b 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.

Что почитать

Другие статьи

\ 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.

Что почитать

Другие статьи

\ 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 faa8a4a..2b715ec 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 — «Главная» и «Перейти к основной странице сайта».

Как тестировать

Проверить консистентность интерактивных элементов поможет ручное и пользовательское тестирование. Примерные шаги:

  • Сравните элементы с одинаковой функциональностью на разных страницах и убедитесь, что у них одинаковые названия и они не сильно отличаются друг от друга визуально.
  • Проведите тестирование с пользователями, чтобы найти элементы с одинаковой функциональностью, которые вызывают трудности.

Что почитать

Другие статьи

\ 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 — «Главная» и «Перейти к основной странице сайта».

Как тестировать

Проверить консистентность интерактивных элементов поможет ручное и пользовательское тестирование. Примерные шаги:

  • Сравните элементы с одинаковой функциональностью на разных страницах и убедитесь, что у них одинаковые названия и они не сильно отличаются друг от друга визуально.
  • Проведите тестирование с пользователями, чтобы найти элементы с одинаковой функциональностью, которые вызывают трудности.

Что почитать

Другие статьи

\ 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 9074a42..1ed18e8 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 Иконки с Iconfinder. Разработано на 11ty. Нашли ошибку? Расскажите мне на GitHub

\ No newline at end of file
+}, true);

Есть букмарклет Скотта О’Хары, который автоматически проходит через элементы и показывает их стили фокуса.

Наконец, если не можете определить на глаз толщину индикатора фокуса, можно посмотреть на его стили в инструменте разработчика в отдельной вкладке с ними. А соотношение контраста можно проверить, например, в WebAIM Contrast Checker.

Что почитать

Другие статьи

\ 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 18eec2a..b501402 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;
 }
 
@@ -29,4 +29,4 @@
     outline: none;
 }
Если в стилях есть такие строчки про фокус и больше ничего, вы нарушаете критерий про видимость фокуса. Лучше так не делать. Можно вообще не трогать фокус или задать ему другие стили через outline или с помощью border.
Кроме старого-доброго :focus можно использовать :focus-visible. Этот псевдокласс задаёт стили только для клавиатурного фокуса. Имейте в виду, что это может запутать пользователей, которые совмещают клавиатуру и мышь. Их может смутить то, что где-то стили фокуса есть, а где-то нет.
Примеры соответствия критерию
  • При фокусе на поле с почтой вокруг него появляется зелёная рамка, которую хорошо видно на белом фоне.
  • При фокусе на ссылке её текст становится белым, а фон — тёмно-синим. Ссылку хорошо видно на белом фоне.
На сайте Xbox у всех интерактивных элементов есть стили фокуса, хотя они не очень констистентные. В каки-то случаях это жирная пунктирная линия, в каких-то двойная сплошная рамка. Внутри она синяя, снаружи белая.
В фокусе ссылка на Elden Ring Deluxe Edition. Видна цена и скидка в 20%. После ссылки в фокусе идёт блок с похожими играми — Thymesia, Cult Lamb, Isaac, Diablo 2 и другими.
Страница игры Elden Ring на сайте Xbox.
Примеры барьеров
  • При фокусе на чёрной кнопке с белым текстом вокруг неё появляется тонкая чёрная рамка. Её трудно увидеть.
  • При фокусе на ссылке она никак визуально не изменяется.
На сайте Pixar у всех интерактивных элементов отменены стили фокуса и используется outline: 0. Это можно проверить с помощью клавиши Tab и Tab + Shift.
На сайте PlayStation у элементов есть стили фокуса, но некоторые элементы в неинтерактивном состоянии выглядят как будто они в фокусе. Например, на скриншоте фокус сделан на кнопке «Learn More» («Узнать больше»). Это видно благодаря синей рамке вокруг неё. У ссылки «PS5 Console» точно такая же синяя рамка в неактивном состоянии. Из-за этого трудно понять, где на самом деле сейчас фокус.
Выделена кнопка и ссылка. На кнопке «Узнать больше» сделан фокус. Он выглядит как синяя рамка со скруглёнными углами. После кнопки располодена ссылка «PS5 Console» c текстом и изображением с белой консолью и контролом, который лежит перед ней. Вокруг ссылки видна синяя рамка со скруглёнными углами, которая похожа на фокус у кнопки.
Главная страница сайта PlayStation.
Как тестировать
Критерий тестируют смешанным способом.
  • Найдите все интерактивные элементы с помощью Tab или скриптом.
  • Убедитесь, что у всех элементов есть видимый фокус.
Найти интерактивные элементы на странице можно разными способами. Например, использовать букмарклеты ANDI или Force Show Keyboard Focus. Ещё можно написать свой небольшой скрипт и собирать интерактивные элементы в консоли в браузере.
document.addEventListener('focus', () => {
     console.log(document.activeElement);
-}, true);
Букмарклет Скотта О’Хары автоматически проходит через элементы и показывает их стили фокуса.
Что почитать
Другие статьи
© Татьяна Фокина, 2021–2024 Иконки с Iconfinder. Разработано на 11ty. Нашли ошибку? Расскажите мне на GitHub

\ No newline at end of file
+}, true);

Букмарклет Скотта О’Хары автоматически проходит через элементы и показывает их стили фокуса.

Что почитать

Другие статьи

\ No newline at end of file diff --git a/ru/articles/wcag-info-and-relationships/index.html b/ru/articles/wcag-info-and-relationships/index.html index a1d3b1e..5d70e83 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-атрибуты.

Проверить автоматически основную структуру страниц и разметку в целом помогут:

Ещё можно посмотреть вручную код в инструменте разработчика в браузере или отключить временно стили на странице. Крайне полезно также послушать страницу со скринридером.

Что почитать

Другие статьи

\ 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-атрибуты.

Проверить автоматически основную структуру страниц и разметку в целом помогут:

Ещё можно посмотреть вручную код в инструменте разработчика в браузере или отключить временно стили на странице. Крайне полезно также послушать страницу со скринридером.

Что почитать

Другие статьи

\ No newline at end of file diff --git a/ru/articles/wcag-keyboard/index.html b/ru/articles/wcag-keyboard/index.html index fee7cea..b5f8670 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 и пробела и других клавиш, если они поддерживаются.
  • Если элемент прокручивается, попробуйте это сделать с помощью стрелок вверх, вниз, вправо и влево.
  • Проверьте, есть ли альтернативный способ взаимодействия с элементом с помощью клавиатуры.

Что почитать

Другие статьи

\ 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 и пробела и других клавиш, если они поддерживаются.
  • Если элемент прокручивается, попробуйте это сделать с помощью стрелок вверх, вниз, вправо и влево.
  • Проверьте, есть ли альтернативный способ взаимодействия с элементом с помощью клавиатуры.

Что почитать

Другие статьи

\ 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 a0a6d26..f9cffc8 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="Золотистый ретривер с красным ошейником лежит на лужайке.
     Он повёрнут вправо, положил голову на передние лапы и смотрит на
@@ -54,4 +54,4 @@
 	⠀⠀⠀⠀⠀⠀⠀⠈⠙⠓⠲⠦⢤⣤⣤⣀⣀⣀⣉⣉⣉⣉⣉⡉⢉⣉⣉⣉⣉⣩⣭⠟⠛⠷⣄⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
 	⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠈⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠁⠀⠀⠀⠀⠀⠈⠙⢦⡀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
 	⠄⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢿⣄⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
-</div>
Примеры соответствия критерию
  • Содержимое диаграммы подробно описано в параграфе перед ней, у самой картинки есть alt с текстом «График роста продаж в 2077. Расшифровка перед картинкой».
  • В тексте статьи про красную панду картинка с ней. У неё такое текстовое описание: «Красная панда лежит на ветке дерева и зевает. У неё более светлая, кажется что светло-коричневая голова, белые уши и центральная часть морды с закрученными вниз вибриссами. Грудь чёрного цвета. Спина и полосатый хвост оранжевого цвета».
  • В тексте есть анимация с демонстрацией работы книгопечатного станка Гутенберга. До анимации подробно рассказано о принципе работы станка, у самой анимации короткая текстовая альтернатива.
  • Ссылка на запись подкаста «Выпуск 23. Почему люди сходят с ума по голубиным гонкам». Рядом расположена ещё одна ссылка на текстовую расшифровку этого выпуска «Текстовая расшифровка выпуска 23».
  • В образовательном сервисе, когда выбираешь ответ, есть два звуковых оповещения о том, что пользователь ответил правильно или ошибся. Кроме оповещения под блоком ответов появляется текст об этом.
  • В меню сайта ссылка с кнопкой с иконкой с домом. У неё есть aria-label с текстом «На главную».
  • У строки поиска кнопка с иконкой лупы. Внутри кнопки есть визуально скрытый <span> с текстом «Искать».
На сайте MDN в некоторых кнопках и ссылках используются картинки. При этом у всех них есть текстовые альтернативы. Например, ссылка с логотипом MDN в главном меню в хедере страницы подписана с помощью aria-label как «MDN homepage».
Открыт инструмент разработчика Chrome, выделен логотип и часть соответствующего ему HTML-кода. В коде это ссылка с `aria-label` с содержимым «MDN homepage». Логотип выглядит как большая светло-голубая буква «M» под наклоном, после неё идёт маленькая надпись «mdn» с нижним подчёркиванием.
Главная MDN со ссылкой с SVG-картинкой в главном меню.
Примеры барьеров
  • На странице размещена иллюстрация с птеродактилем. Эта картинка важна для понимания смысла текста. alt картинки: «Картинка с птеродактилем».
  • В меню есть декоративные разделители в виде иконок с ёлочными игрушками между пунктами списка ссылок. У них одинаковый alt «Ёлочная игрушка».
  • Ссылка с иконкой с домом. У неё нет никакого альтернативного текста.
  • У строки поиска кнопка с иконкой лупы. Внутри кнопки есть визуально скрытый <span> с текстом «Иконка лупы».
  • ASCII-графика со схемой организации папок. К ней нет описания в виде текста.
  • Капча с несколькими картинками с лодками и без них. У картинок нет никакого описания в виде текста, их также нельзя прослушать или выбрать альтернативный способ определения робот ты или нет.
На сайте Fox News бывают обзоры и аналитика с гифками, которые вставлены через тег <img>. В тексте про рождественские ёлки у анимации корректные альтернативные описания, которые раскрывают её содержание. Например, «80 % искусственных деревьев в мире производится в Китае, согласно данным Министерства торговли». Однако критерий 1.1.1 на странице не соблюдается.
Во-первых, alt полностью повторяет текст подписи к картинке в <figcaption>. Во-вторых, в боковом меню есть плавающая ссылка на подборку новостей и историй про Штаты. У картинки в ссылке нет alt или другой текстовой альтернативы.
Две колонки. В первой текст материала и кадр из анимации с тремя рисунками украшенных рождественских ёлок на фоне флага Китая. Текст альтернативного описания и подписи к картинке полностью совпадают. Во второй колонке ссылка-баннер с картинкой. На фоне американского флага надпись «Proud American. Click here for patriotic news and ispiring stories». У картинки нет альтернативного описания.
Статья с гифками и ссылкой с картинкой на Fox News.
На сайте The Row есть много проблем с текстовыми альтернативами для нетекстового контента. На странице с новинками одежды в новом зимнем сезоне у смысловых картинок вообще нет alt.
Шестой образ из зимней коллекции 2022 года The Row. На странице четыре картинки — одна большая по центру, три другие более маленькие сбоку. У всех картинок нет альтернативного описания. На выбранной картинке девушка с тёмной кожей и короткой стрижкой. На ней светло-бежевое стёганное пальто длинной до лодыжек. Поверх пальто повязан объёмный шарф такого же бежевого оттенка. Из-под пальто выглядывают спортивные вязанные брюки цвета слоновой кости, на ногах кожанные кроссовки с зелёными вставками на пятке. На других картинках-превью то же пальто, что на девушке, брюки из шерсти и кроссовки из кожи.
Страница с образами зима 2022 на сайте The Row.
Как тестировать
Протестировать текстовую альтернативу для изображений поможет смешанное тестирование.
  • Найдите все декоративные картинки в CSS. Можно найти их в коде (background, background-image, content) или закрасьте одним цветом.
  • Найдите в коде <img>, type="image", role="img" и <area> и проверьте их описания. Это можно сделать поиском по проекту, инструментом для автоматического тестирования или отключив картинки в браузере.
Отсутствующий alt находят все популярные автоматические инcтрументы — Deque Axe, IBM Accessibility Assessment и другими. Однако в критерии про текстовую альтернативу также важно то, как именно описан нетекстовый контент. Поэтому можно сразу проверять alt в букмарклетах ANDI, Images Bookmarklet или любым другим похожим скриптом.
Ещё один способ проверить описание картинок — расширение Web Developer extension. В нём можно удалить картинки со страницы. Для этого выберите опцию «Отключить все стили и картинки» («Disable All Styles and Images») → «Скрыть картинки» («Hide Images»).
Кнопки и ссылки тоже хорошо тестировать смешанным способом:
  • Найдите все <a> и <button>, у которых вместо текстового названия картинка.
  • Проверьте их текстовую альтернативу в редакторе кода или в инструменте разработчика в браузере.
Видео, аудио и анимацию придётся проверять вручную:
  • Найдите всю анимацию, видео и аудио контент. Можно найти их в коде по <video>, <audio>, @keyframes, animation, файлам с расширениями .gif, .mp4, .avi, .mp3 и так далее.
  • Проверьте, есть ли на странице связанная с ними текстовая альтернатива.
Что почитать
Как описывать картинки
Другие статьи
© Татьяна Фокина, 2021–2024 Иконки с Iconfinder. Разработано на 11ty. Нашли ошибку? Расскажите мне на GitHub

\ No newline at end of file
+</div>

Примеры соответствия критерию

  • Содержимое диаграммы подробно описано в параграфе перед ней, у самой картинки есть alt с текстом «График роста продаж в 2077. Расшифровка перед картинкой».
  • В тексте статьи про красную панду картинка с ней. У неё такое текстовое описание: «Красная панда лежит на ветке дерева и зевает. У неё более светлая, кажется что светло-коричневая голова, белые уши и центральная часть морды с закрученными вниз вибриссами. Грудь чёрного цвета. Спина и полосатый хвост оранжевого цвета».
  • В тексте есть анимация с демонстрацией работы книгопечатного станка Гутенберга. До анимации подробно рассказано о принципе работы станка, у самой анимации короткая текстовая альтернатива.
  • Ссылка на запись подкаста «Выпуск 23. Почему люди сходят с ума по голубиным гонкам». Рядом расположена ещё одна ссылка на текстовую расшифровку этого выпуска «Текстовая расшифровка выпуска 23».
  • В образовательном сервисе, когда выбираешь ответ, есть два звуковых оповещения о том, что пользователь ответил правильно или ошибся. Кроме оповещения под блоком ответов появляется текст об этом.
  • В меню сайта ссылка с кнопкой с иконкой с домом. У неё есть aria-label с текстом «На главную».
  • У строки поиска кнопка с иконкой лупы. Внутри кнопки есть визуально скрытый <span> с текстом «Искать».

На сайте MDN в некоторых кнопках и ссылках используются картинки. При этом у всех них есть текстовые альтернативы. Например, ссылка с логотипом MDN в главном меню в хедере страницы подписана с помощью aria-label как «MDN homepage».

Открыт инструмент разработчика Chrome, выделен логотип и часть соответствующего ему HTML-кода. В коде это ссылка с `aria-label` с содержимым «MDN homepage». Логотип выглядит как большая светло-голубая буква «M» под наклоном, после неё идёт маленькая надпись «mdn» с нижним подчёркиванием.
Главная MDN со ссылкой с SVG-картинкой в главном меню.

Примеры барьеров

  • На странице размещена иллюстрация с птеродактилем. Эта картинка важна для понимания смысла текста. alt картинки: «Картинка с птеродактилем».
  • В меню есть декоративные разделители в виде иконок с ёлочными игрушками между пунктами списка ссылок. У них одинаковый alt «Ёлочная игрушка».
  • Ссылка с иконкой с домом. У неё нет никакого альтернативного текста.
  • У строки поиска кнопка с иконкой лупы. Внутри кнопки есть визуально скрытый <span> с текстом «Иконка лупы».
  • ASCII-графика со схемой организации папок. К ней нет описания в виде текста.
  • Капча с несколькими картинками с лодками и без них. У картинок нет никакого описания в виде текста, их также нельзя прослушать или выбрать альтернативный способ определения робот ты или нет.

На сайте Fox News бывают обзоры и аналитика с гифками, которые вставлены через тег <img>. В тексте про рождественские ёлки у анимации корректные альтернативные описания, которые раскрывают её содержание. Например, «80 % искусственных деревьев в мире производится в Китае, согласно данным Министерства торговли». Однако критерий 1.1.1 на странице не соблюдается.

Во-первых, alt полностью повторяет текст подписи к картинке в <figcaption>. Во-вторых, в боковом меню есть плавающая ссылка на подборку новостей и историй про Штаты. У картинки в ссылке нет alt или другой текстовой альтернативы.

Две колонки. В первой текст материала и кадр из анимации с тремя рисунками украшенных рождественских ёлок на фоне флага Китая. Текст альтернативного описания и подписи к картинке полностью совпадают. Во второй колонке ссылка-баннер с картинкой. На фоне американского флага надпись «Proud American. Click here for patriotic news and ispiring stories». У картинки нет альтернативного описания.
Статья с гифками и ссылкой с картинкой на Fox News.

На сайте The Row есть много проблем с текстовыми альтернативами для нетекстового контента. На странице с новинками одежды в новом зимнем сезоне у смысловых картинок вообще нет alt.

Шестой образ из зимней коллекции 2022 года The Row. На странице четыре картинки — одна большая по центру, три другие более маленькие сбоку. У всех картинок нет альтернативного описания. На выбранной картинке девушка с тёмной кожей и короткой стрижкой. На ней светло-бежевое стёганное пальто длинной до лодыжек. Поверх пальто повязан объёмный шарф такого же бежевого оттенка. Из-под пальто выглядывают спортивные вязанные брюки цвета слоновой кости, на ногах кожанные кроссовки с зелёными вставками на пятке. На других картинках-превью то же пальто, что на девушке, брюки из шерсти и кроссовки из кожи.
Страница с образами зима 2022 на сайте The Row.

Как тестировать

Протестировать текстовую альтернативу для изображений поможет смешанное тестирование.

  • Найдите все декоративные картинки в CSS. Можно найти их в коде (background, background-image, content) или закрасьте одним цветом.
  • Найдите в коде <img>, type="image", role="img" и <area> и проверьте их описания. Это можно сделать поиском по проекту, инструментом для автоматического тестирования или отключив картинки в браузере.

Отсутствующий alt находят все популярные автоматические инcтрументы — Deque Axe, IBM Accessibility Assessment и другими. Однако в критерии про текстовую альтернативу также важно то, как именно описан нетекстовый контент. Поэтому можно сразу проверять alt в букмарклетах ANDI, Images Bookmarklet или любым другим похожим скриптом.

Ещё один способ проверить описание картинок — расширение Web Developer extension. В нём можно удалить картинки со страницы. Для этого выберите опцию «Отключить все стили и картинки» («Disable All Styles and Images») → «Скрыть картинки» («Hide Images»).

Кнопки и ссылки тоже хорошо тестировать смешанным способом:

  • Найдите все <a> и <button>, у которых вместо текстового названия картинка.
  • Проверьте их текстовую альтернативу в редакторе кода или в инструменте разработчика в браузере.

Видео, аудио и анимацию придётся проверять вручную:

  • Найдите всю анимацию, видео и аудио контент. Можно найти их в коде по <video>, <audio>, @keyframes, animation, файлам с расширениями .gif, .mp4, .avi, .mp3 и так далее.
  • Проверьте, есть ли на странице связанная с ними текстовая альтернатива.

Что почитать

Как описывать картинки

Другие статьи

\ No newline at end of file diff --git a/ru/articles/wcag-page-titled/index.html b/ru/articles/wcag-page-titled/index.html index 21acf1e..249e02d 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>
@@ -29,4 +29,4 @@
     <body>
         …
     </body>
-</html>
Примеры соответствия критерию
  • Главная страница справочника MDN называется «MDN Web Docs», а отдельная страница про свойство width в разделе CSS — «width - CSS: Cascading Style Sheets | MDN».
  • Главная страница справочника Доки называется «Дока», а отдельная страница про свойство width в разделе CSS — «width — CSS — Дока».
Хороший пример доступного и динамически изменяющегося заголовка — веб-версия Notion. Когда создаёте новую страницу, у неё стандартный <title> «Untitled». Он изменяется после того, как вводите название в поле для основного заголовка страницы. Главное не забывать это делать, если планируете делиться страницей с другими пользователями.
Примеры барьеров
  • На сайте про кофе на главной странице вообще нет <title>.
  • У главной страницы сайта <title> без текстового содержимого.
  • На сайте про разведение лягушек у страниц есть <title> с содержимым, которое их не описывает. Например, «Untitled Page», «Новая страница» и «Страница 2».
  • В интернет-магазине у страниц товаров одинаковое название «Страница товара».
Как тестировать
Критерий обычно тестируют смешанным способом.
  • Откройте нужную страницу.
  • Проверьте, есть ли у неё тег <title> и содержимое в нём.
  • Если тег не пустой, хорошо ли он описывает тему или цель страницы и насколько уникален.
Наличие тега <title> легко проверить любым автоматическим инструментом. Например, Axe, Lighthouse или IBM Equal Access Checker.
Содержимое заголовков лучше проверять руками в браузере. Откройте нужную страницу и наведите курсор на вкладку, если название длинное. Также можно проверять код страницы в инструменте разработчика в удобном вам браузере. Ещё поможет букмарклет Page Title, который выводит название страницы в диалоговом окне.
Что почитать
Другие статьи
© Татьяна Фокина, 2021–2024 Иконки с Iconfinder. Разработано на 11ty. Нашли ошибку? Расскажите мне на GitHub

\ No newline at end of file
+</html>

Примеры соответствия критерию

  • Главная страница справочника MDN называется «MDN Web Docs», а отдельная страница про свойство width в разделе CSS — «width - CSS: Cascading Style Sheets | MDN».
  • Главная страница справочника Доки называется «Дока», а отдельная страница про свойство width в разделе CSS — «width — CSS — Дока».

Хороший пример доступного и динамически изменяющегося заголовка — веб-версия Notion. Когда создаёте новую страницу, у неё стандартный <title> «Untitled». Он изменяется после того, как вводите название в поле для основного заголовка страницы. Главное не забывать это делать, если планируете делиться страницей с другими пользователями.

Примеры барьеров

  • На сайте про кофе на главной странице вообще нет <title>.
  • У главной страницы сайта <title> без текстового содержимого.
  • На сайте про разведение лягушек у страниц есть <title> с содержимым, которое их не описывает. Например, «Untitled Page», «Новая страница» и «Страница 2».
  • В интернет-магазине у страниц товаров одинаковое название «Страница товара».

Как тестировать

Критерий обычно тестируют смешанным способом.

  • Откройте нужную страницу.
  • Проверьте, есть ли у неё тег <title> и содержимое в нём.
  • Если тег не пустой, хорошо ли он описывает тему или цель страницы и насколько уникален.

Наличие тега <title> легко проверить любым автоматическим инструментом. Например, Axe, Lighthouse или IBM Equal Access Checker.

Содержимое заголовков лучше проверять руками в браузере. Откройте нужную страницу и наведите курсор на вкладку, если название длинное. Также можно проверять код страницы в инструменте разработчика в удобном вам браузере. Ещё поможет букмарклет Page Title, который выводит название страницы в диалоговом окне.

Что почитать

Другие статьи

\ No newline at end of file diff --git a/ru/articles/wcag-sensory-characteristics/index.html b/ru/articles/wcag-sensory-characteristics/index.html index a3907ac..d4f7659 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-кода.

Как тестировать

С поиском проблем с сенсорными характеристиками поможет только ручное тестирование.

  • Найдите страницы, где есть инструкции.
  • Убедитесь, что в них описан не только внешний вид элементов и их положение на странице.

Что почитать

Другие статьи

\ 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-кода.

Как тестировать

С поиском проблем с сенсорными характеристиками поможет только ручное тестирование.

  • Найдите страницы, где есть инструкции.
  • Убедитесь, что в них описан не только внешний вид элементов и их положение на странице.

Что почитать

Другие статьи

\ 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 7e86ea1..edbff34 100644 --- a/ru/articles/wcag-target-size/index.html +++ b/ru/articles/wcag-target-size/index.html @@ -21,11 +21,11 @@ }, "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 {
     display: inline-block;
     min-width: 44px;
     min-height: 44px;
-}
Примеры соответствия критериям
  • Кнопка размером 44px на 48px.
  • Две ссылки в меню размера 20px на 20px и с расстоянием между ними в 4px.
  • Несколько кнопок с размером 24px на 20px и с расстоянием между ними в 10px.
  • Две кнопки, которые делают одно и то же. Одна из них 20px на 20px, другая — 46px на 44px. Это исключение.
  • Якорная ссылка меньше 24px на 24px. Пользователь может проскролить к нужной части страницы и не пользоваться ссылкой. Это исключение.
  • Маркеры на карте, которые расположены близко друг к другу. Это исключение.
  • Иконка с вопросительным знаком размером 24px на 24px в конце предложения, которая показывает тултип. Это исключение.
  • Ссылки в сноске размером 12px, расстояние между ними меньше 12px. Это исключение.
На сайте Pocket в меню несколько кнопок. Их размер 44px на 44.06px. Это соответствует максимальному требованию к размеру целей.
В меню выделена кнопка с иконкой в виде плюса. На неё наведён курсор в режиме инструмента разработчика, видна информация об элементе. Она размера 44 пикселя на 44.06 пикселя.
Меню с кнопками в десктопной версии Pocket.
На сайте NRK есть блок с информацией об авторе текста и его контактами. В нём ссылка на почту, её размер 196.18px на 41px. Это соответствует максимальным требованиям о размере цели, так как между ссылкой и другими интерактивными элементами большое расстояние.
Блок с информацией об авторе текста. Это литературный критик и автор нескольких книг для детей. Её имя Анна-Катрина Штрайм. Курсор в режиме разработчика наведён на ссылку с подписью «Напишите мне на почту». Её размер 196.18 пикселей на 41 пиксель.
Ссылка на почту автора текста на сайте NRK.
На сайте Chanel есть слайдеры с кнопками для переключения к конкретным слайдам и для перехода к следующему или предыдущему. Размер кнопок для переключения к конкретным слайдам всего 20px на 20px. Кнопки для перехода к следующему слайду 40px на 40px. Получается, что размеры элементов отвечают минимальному требованию, но не проходят максимальное.
Первый слайд в слайдере из четырёх. Курсор в режиме разработчика наведён на небольшую точку под слайдером. Это span и он 20 на 20 пикселей. Другой курсор наведён на кнопку со стрелкой, указывающей влево. Её размер 40 на 40 пикселей.
Слайдер с двумя видами кнопок на сайте Chanel.
Примеры барьеров
  • Кнопка размером 20px на 20px.
  • Список ссылок, восота которых меньше 24px, а ещё между ними небольшие расстояния.
На сайте Zara в выпадающем списке меню со ссылками небольшое расстояние между элементами, а их высота всего 16px. Так что они не соответствуют минимальному требованию.
Открыто боковое меню со списком всех товаров. В режиме разработчика выделена ссылка «База». Она 100.76 на 16 пикселей. Между ссылками нет свободного пространства.
Выпадающее меню со списком ссылок на сайте Zara.
На сайте Mango под фотографиями товаров есть кнопки для выбора цвета. Их размер всего 16px на 16px, поэтому они не соответствуют минимальному требованию.
Курсор в режиме разработчика наведён на круглую кнопку бордового цвета. Её размер 16 на 16 пикселей.
Кнопки для выбора цвета товара на сайте Mango.
Как тестировать
Проверить размеры интерактивных элементов поможет смешанное тестирование.
  • В браузерах приходят на помощь инструменты разработчика. В них можно проверять фактический размер элементов и область клика.
  • На Andriod есть приложение для автоматического тестирования Accessibility Checker. Оно проверяет в том числе размеры кнопок в мобильных приложениях.
  • В Figma, Sketch и Adobee XD можно использовать платный плагин Adee.
Что почитать
Другие статьи
© Татьяна Фокина, 2021–2024 Иконки с Iconfinder. Разработано на 11ty. Нашли ошибку? Расскажите мне на GitHub

\ No newline at end of file
+}

Примеры соответствия критериям

  • Кнопка размером 44px на 48px.
  • Две ссылки в меню размера 20px на 20px и с расстоянием между ними в 4px.
  • Несколько кнопок с размером 24px на 20px и с расстоянием между ними в 10px.
  • Две кнопки, которые делают одно и то же. Одна из них 20px на 20px, другая — 46px на 44px. Это исключение.
  • Якорная ссылка меньше 24px на 24px. Пользователь может проскролить к нужной части страницы и не пользоваться ссылкой. Это исключение.
  • Маркеры на карте, которые расположены близко друг к другу. Это исключение.
  • Иконка с вопросительным знаком размером 24px на 24px в конце предложения, которая показывает тултип. Это исключение.
  • Ссылки в сноске размером 12px, расстояние между ними меньше 12px. Это исключение.

На сайте Pocket в меню несколько кнопок. Их размер 44px на 44.06px. Это соответствует максимальному требованию к размеру целей.

В меню выделена кнопка с иконкой в виде плюса. На неё наведён курсор в режиме инструмента разработчика, видна информация об элементе. Она размера 44 пикселя на 44.06 пикселя.
Меню с кнопками в десктопной версии Pocket.

На сайте NRK есть блок с информацией об авторе текста и его контактами. В нём ссылка на почту, её размер 196.18px на 41px. Это соответствует максимальным требованиям о размере цели, так как между ссылкой и другими интерактивными элементами большое расстояние.

Блок с информацией об авторе текста. Это литературный критик и автор нескольких книг для детей. Её имя Анна-Катрина Штрайм. Курсор в режиме разработчика наведён на ссылку с подписью «Напишите мне на почту». Её размер 196.18 пикселей на 41 пиксель.
Ссылка на почту автора текста на сайте NRK.

На сайте Chanel есть слайдеры с кнопками для переключения к конкретным слайдам и для перехода к следующему или предыдущему. Размер кнопок для переключения к конкретным слайдам всего 20px на 20px. Кнопки для перехода к следующему слайду 40px на 40px. Получается, что размеры элементов отвечают минимальному требованию, но не проходят максимальное.

Первый слайд в слайдере из четырёх. Курсор в режиме разработчика наведён на небольшую точку под слайдером. Это span и он 20 на 20 пикселей. Другой курсор наведён на кнопку со стрелкой, указывающей влево. Её размер 40 на 40 пикселей.
Слайдер с двумя видами кнопок на сайте Chanel.

Примеры барьеров

  • Кнопка размером 20px на 20px.
  • Список ссылок, восота которых меньше 24px, а ещё между ними небольшие расстояния.

На сайте Zara в выпадающем списке меню со ссылками небольшое расстояние между элементами, а их высота всего 16px. Так что они не соответствуют минимальному требованию.

Открыто боковое меню со списком всех товаров. В режиме разработчика выделена ссылка «База». Она 100.76 на 16 пикселей. Между ссылками нет свободного пространства.
Выпадающее меню со списком ссылок на сайте Zara.

На сайте Mango под фотографиями товаров есть кнопки для выбора цвета. Их размер всего 16px на 16px, поэтому они не соответствуют минимальному требованию.

Курсор в режиме разработчика наведён на круглую кнопку бордового цвета. Её размер 16 на 16 пикселей.
Кнопки для выбора цвета товара на сайте Mango.

Как тестировать

Проверить размеры интерактивных элементов поможет смешанное тестирование.

  • В браузерах приходят на помощь инструменты разработчика. В них можно проверять фактический размер элементов и область клика.
  • На Andriod есть приложение для автоматического тестирования Accessibility Checker. Оно проверяет в том числе размеры кнопок в мобильных приложениях.
  • В Figma, Sketch и Adobee XD можно использовать платный плагин Adee.

Что почитать

Другие статьи

\ No newline at end of file diff --git a/ru/index.html b/ru/index.html index b0283b3..a06d163 100644 --- a/ru/index.html +++ b/ru/index.html @@ -1 +1 @@ -Блог о цифровой доступности

Что тут происходит?

Привет, я Татьяна Фокина, но вы можете звать меня просто Таня. Я специалистка по веб-доступности, которая любит создавать дружелюбные интерфейсы и обсуждать цифровую доступность с другими (иногда посреди ночи).

Что я делаю? Пишу и перевожу статьи, редачу раздел «Доступность» в Доке — дружелюбном справочнике для разработчиков. С недавних пор стала ещё и ведущей первого русскоязычного подкаста про доступность и инклюзию «Инклюзивный ананас» (не спрашивайте почему ананас и почему инклюзивный). Давным-давно организовывала петербургский митап pitera11y_meetup.

В этом блоге делюсь практическими советами, хаками, полезными ссылками, своими мыслями и просто интересными находками о доступной разработке и инклюзии ✨

Если хотите спросить меня о моих статьях или доступности, ищите меня на LinkedIn или в Твиттере.

Последние статьи

Клавиатура

Разбираемся с критерием WCAG про доступность интерфейса для клавиатуры.

  • WCAG
  • Клавиатура
  • HTML

Внешний вид фокуса

Как должны выглядеть элементы при фокусе с клавиатуры по мнению WCAG 2.2.

  • WCAG
  • Дизайн
  • CSS
  • Клавиатура
Все статьи
\ No newline at end of file +Блог о цифровой доступности

Что тут происходит?

Привет, я Татьяна Фокина, но вы можете звать меня просто Таня. Я специалистка по веб-доступности, которая любит создавать дружелюбные интерфейсы и обсуждать цифровую доступность с другими (иногда посреди ночи).

Что я делаю? Пишу и перевожу статьи, редачу раздел «Доступность» в Доке — дружелюбном справочнике для разработчиков. С недавних пор стала ещё и ведущей первого русскоязычного подкаста про доступность и инклюзию «Инклюзивный ананас» (не спрашивайте почему ананас и почему инклюзивный). Давным-давно организовывала петербургский митап pitera11y_meetup.

В этом блоге делюсь практическими советами, хаками, полезными ссылками, своими мыслями и просто интересными находками о доступной разработке и инклюзии ✨

Если хотите спросить меня о моих статьях или доступности, ищите меня на LinkedIn или в Твиттере.

Последние статьи

Клавиатура

Разбираемся с критерием WCAG про доступность интерфейса для клавиатуры.

  • WCAG
  • Клавиатура
  • HTML

Внешний вид фокуса

Как должны выглядеть элементы при фокусе с клавиатуры по мнению WCAG 2.2.

  • WCAG
  • Дизайн
  • CSS
  • Клавиатура
Все статьи
\ No newline at end of file diff --git a/styles/styles.css b/styles/styles.css index 1e00a60..b4781ad 100644 --- a/styles/styles.css +++ b/styles/styles.css @@ -1 +1 @@ -.base[data-theme=light]{--decorative-el-color:#b655f628;--bg-color:#c8d5d6;--bg-part-color:#dae3e4;--text-color:#2f445d;--code-color:#b8c9de;--border-color:#566c87;--color-hover:#b7caca;--menu-elements-color-hover:#6e829b;--button-bg-color:#2f445d;--button-text-color:#c8d5d6;--img-filter:unset}.base[data-theme=dark]{--decorative-el-color:#b655f628;--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)}@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:clamp(1.45rem,1.107rem + 2.143vw,2.2rem);--step-2:clamp(1.25rem,.953rem + 1.857vw,1.9rem);--step-1:clamp(1.05rem,.89rem + 1vw,1.4rem);--step-0:clamp(.8rem,.709rem + .571vw,1rem);--step--1:clamp(.7rem,.654rem + .286vw,.8rem);--step--2:clamp(.6rem,.554rem + .286vw,.7rem)}.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}}*,:before,:after{box-sizing:border-box;margin:0}.page{font-size:20px}.base{font-family:IBM Plex Sans,Arial,Helvetica,sans-serif;font-size:var(--step-0);color:var(--text-color);background:var(--bg-color);flex-direction:column;min-height:100vh;margin:0;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}.wrapper p{font-size:var(--step-0);margin:20px 0;line-height:1.6}.wrapper p:first-child{margin-top:0}.wrapper p:last-child{margin-bottom:0}.wrapper hr{background:var(--text-color);border:0;width:20%;height:2px;margin:48px auto;display:block}::selection{background:var(--decorative-el-color)}.wrapper figure{margin:0}.wrapper figcaption{font-size:var(--step--1);margin:8px 0 20px}.wrapper small{font-size:var(--step--1)}.wrapper 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:2px}.wrapper pre code{padding:36px;display:block;overflow-x:auto}.wrapper kbd{font-family:IBM Plex Mono,Courier New,monospace}.wrapper samp{font-family:IBM Plex Sans,Arial,Helvetica,sans-serif}.wrapper blockquote{border-left:4px solid var(--border-color);word-wrap:break-word}.wrapper blockquote,.wrapper blockquote ol,.wrapper blockquote ul{margin:0;padding-left:24px}.wrapper a{color:var(--text-color);border-bottom:2px solid var(--border-color);text-decoration:none}.wrapper a:hover{background:var(--color-hover)}.wrapper a:focus-visible{outline:2px solid var(--border-color);outline-offset:2px}.all-articles-link{margin-top:24px;display:inline-block}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{font-size:var(--step-0);margin-top:28px;margin-bottom:14px;line-height:1.5}.wrapper img{filter:var(--img-filter);max-width:100%;height:auto;display:block}@media (forced-colors){.card{border:2px solid #0000}.card:focus-within:has(:focus-visible){outline:2px solid #0000}}@media (inverted-colors){.wrapper img,.wrapper video{filter:invert()}}.article-inf{text-align:center;margin-bottom:64px}.article-date{font-size:var(--step--1);margin-top:12px;display:inline-block}.note{font-size:var(--step--1);background:var(--bg-part-color);border-radius:4px;margin:20px 0;padding:20px;display:flex;position:relative}.note .note__text{font-size:var(--step--1);word-break:break-word;margin:0;padding-left:32px}.note__emoji{display:block;position:absolute;top:20px}.header{flex-direction:column;align-items:center;padding-top:20px;padding-bottom:20px;display:flex}@media (width>=576px){.header{flex-direction:row}}.nav{flex-flow:wrap;justify-content:center;width:100%;margin-bottom:20px;padding-right:0;display:flex}@media (width>=576px){.nav{justify-content:space-between;margin-bottom:0;padding-right:16px}}.nav__list{flex-direction:row;margin:0;padding:0;list-style:none;display:flex}@media (width>=576px){.nav__list{align-items:center;gap:8px;margin:0}}.nav__list-img{fill:currentColor;forced-color-adjust:auto}.nav .nav__list-link{border-bottom:0;align-items:center;width:100%;padding:20px;line-height:1.7;transition:color .2s;display:inline-flex;position:relative}.nav .nav__list-link:hover{background:inherit;color:var(--menu-elements-color-hover)}.nav__list-text{padding-left:8px}.logo{display:flex}.logo__image{width:54px;height:auto}@media (width>=992px){.logo__image{width:62px}}.logo__image{fill:currentColor;forced-color-adjust:auto}.nav .logo__link{border-bottom:0;display:inline-flex}.nav .logo__link:hover{background:inherit}.nav .logo__link:hover .logo__image{fill:var(--menu-elements-color-hover)}.theme-switcher{border:2px solid var(--border-color);padding:4px;border-radius:32px;padding-inline:4px;display:flex}.theme-switcher__button{color:var(--text-color);cursor:pointer;background:0 0;border:0;border-radius:32px;margin:0;padding:8px 16px;transition:background .2s}.theme-switcher__button:focus-visible{outline:2px solid var(--border-color);outline-offset:1px}.theme-switcher__button:first-child{margin-right:4px}.theme-switcher__button[aria-pressed=true]{color:var(--button-text-color);background:var(--button-bg-color)}.theme-switcher__button[aria-pressed=false]{color:inherit}.theme-switcher__button[aria-pressed=false]:hover{color:var(--button-text-color);background:var(--menu-elements-color-hover)}.footer{flex-direction:column;padding-top:116px;padding-bottom:48px;display:flex}.footer__content{display:inline-block}.footer__content:not(:last-of-type){margin-bottom:8px}.cards--w-margin{margin-top:32px}.cards--in-article{margin:0;padding:0}.card{background:var(--bg-part-color);border-radius:26px;flex-direction:column;justify-content:space-between;width:100%;padding:16px;transition:background .3s;display:flex;position:relative}.card:not(:last-of-type){margin-bottom:20px}.card:before{content:"";position:absolute}.card:hover{background:var(--color-hover)}@media (width>=768px){.card{padding:40px}}.card--short{display:inline-flex}.card__title{margin-top:0}.card:focus-within:has(:focus-visible){outline:2px solid var(--border-color);outline-offset:3px}.card a:focus{outline:0}a.card__title-link{color:inherit;border-bottom:0;font-weight:700;transition:none}a.card__title-link:after{content:"";position:absolute;inset:0}a.card__title-link:hover{color:inherit;background:inherit;border-bottom:0}p.card__description{margin:0 0 16px}.card__description--in-article{margin-top:28px}.card__article-date{font-size:var(--step--1)}.topic-list{flex-wrap:wrap;gap:4px;margin:0;padding:0;list-style:none;display:flex}.topic-list--article{justify-content:center}.topic-list--card{margin:0 0 12px}.topic-list__item{font-size:var(--step--2);color:var(--text-color);border:1px solid var(--border-color);border-radius:10px;padding:4px 8px}.about-blog{margin-bottom:40px} \ No newline at end of file +.base[data-theme=light]{--decorative-el-color:#b655f628;--bg-color:#c8d5d6;--bg-part-color:#dae3e4;--text-color:#2f445d;--code-color:#b8c9de;--border-color:#566c87;--color-hover:#b7caca;--menu-elements-color-hover:#6e829b;--button-bg-color:#2f445d;--button-text-color:#c8d5d6;--img-filter:unset}.base[data-theme=dark]{--decorative-el-color:#b655f628;--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)}@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:clamp(1.45rem,1.107rem + 2.143vw,2.2rem);--step-2:clamp(1.25rem,.953rem + 1.857vw,1.9rem);--step-1:clamp(1.05rem,.89rem + 1vw,1.4rem);--step-0:clamp(.8rem,.709rem + .571vw,1rem);--step--1:clamp(.7rem,.654rem + .286vw,.8rem);--step--2:clamp(.6rem,.554rem + .286vw,.7rem)}.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}}*,:before,:after{box-sizing:border-box;margin:0}.page{font-size:20px}.base{font-family:IBM Plex Sans,Arial,Helvetica,sans-serif;font-size:var(--step-0);color:var(--text-color);background:var(--bg-color);flex-direction:column;min-height:100vh;margin:0;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}p{font-size:var(--step-0);margin:20px 0;line-height:1.6}p:first-child{margin-top:0}p:last-child{margin-bottom:0}.wrapper hr{background:var(--text-color);border:0;width:20%;height:2px;margin:48px auto;display:block}::selection{background:var(--decorative-el-color)}.wrapper figure{margin:0}.wrapper figcaption{font-size:var(--step--1);margin:8px 0 20px}.wrapper small{font-size:var(--step--1)}.wrapper 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:2px}.wrapper pre code{padding:36px;display:block;overflow-x:auto}.wrapper kbd{font-family:IBM Plex Mono,Courier New,monospace}.wrapper samp{font-family:IBM Plex Sans,Arial,Helvetica,sans-serif}.wrapper blockquote{border-left:4px solid var(--border-color);word-wrap:break-word}.wrapper blockquote,.wrapper blockquote ol,.wrapper 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:2px solid var(--border-color);outline-offset:2px}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{font-size:var(--step-0);margin-top:28px;margin-bottom:14px;line-height:1.5}.wrapper img{filter:var(--img-filter);max-width:100%;height:auto;display:block}@media (forced-colors){.cards__item{border:2px solid #0000}.cards__item:focus-within:has(:focus-visible){outline:2px solid #0000}}@media (inverted-colors){.wrapper img,.wrapper video{filter:invert()}}.article-header{text-align:center;margin-bottom:64px}.article-header__date{font-size:var(--step--1);margin-top:12px;display:inline-block}.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;padding-top:20px;padding-bottom:20px;display:flex}@media (width>=576px){.header{flex-direction:row}}.nav{flex-flow:wrap;justify-content:center;width:100%;margin-bottom:20px;padding-right:0;display:flex}@media (width>=576px){.nav{justify-content:space-between;margin-bottom:0;padding-right:16px}}.nav__list{flex-direction:row;margin:0;padding:0;list-style:none;display:flex}@media (width>=576px){.nav__list{align-items:center;gap:8px;margin:0}}.nav__list-img{fill:currentColor;forced-color-adjust:auto}.nav .nav__list-link{border-bottom:0;align-items:center;width:100%;padding:20px;line-height:1.7;transition:color .2s;display:inline-flex;position:relative}.nav .nav__list-link:hover{background:inherit;color:var(--menu-elements-color-hover)}.nav__list-text{padding-left:8px}.logo{display:flex}.logo__image{width:54px;height:auto}@media (width>=992px){.logo__image{width:62px}}.logo__image{fill:currentColor;forced-color-adjust:auto}.nav .logo__link{border-bottom:0;display:inline-flex}.nav .logo__link:hover{background:inherit}.nav .logo__link:hover .logo__image{fill:var(--menu-elements-color-hover)}.theme-switcher{border:2px solid var(--border-color);padding:4px;border-radius:32px;padding-inline:4px;display:flex}.theme-switcher__button{color:var(--text-color);cursor:pointer;background:0 0;border:0;border-radius:32px;margin:0;padding:8px 16px;transition:background .2s}.theme-switcher__button:focus-visible{outline:2px solid var(--border-color);outline-offset:1px}.theme-switcher__button:first-child{margin-right:4px}.theme-switcher__button[aria-pressed=true]{color:var(--button-text-color);background:var(--button-bg-color)}.theme-switcher__button[aria-pressed=false]{color:inherit}.theme-switcher__button[aria-pressed=false]:hover{color:var(--button-text-color);background:var(--menu-elements-color-hover)}.footer{flex-direction:column;padding-top:116px;padding-bottom:48px;display:flex}.footer__content{display:inline-block}.footer__content:not(:last-of-type){margin-bottom:8px}.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:has(:focus-visible){outline:2px solid var(--border-color);outline-offset:3px}.cards__item-heading-link:focus,.cards__item-link:focus{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-description{margin:0}.cards__item-date{font-size:var(--step--1)}.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}.about-blog{margin-bottom:40px} \ No newline at end of file diff --git a/styles/styles.css.map b/styles/styles.css.map index cfda45f..5016d84 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/_fonts.scss","../../src/styles/basic/_typography.scss","../../src/styles/basic/_global.scss","../../src/styles/_mixins-and-functions.scss","../../src/styles/basic/_layout.scss","../../src/styles/_variables.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","../../src/styles/components/_about-blog.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;;;AC5BD;EACC;EACA;EACA;EACA;EACA;;AAKD;EACC;EACA;EACA;EACA;EACA;;AAKD;EACC;EACA;EACA;EACA;EACA;;ACpBD;EACC;EACA;EACA;EACA;EACA;EACA;;;ACTD;EACC;EACA;EAEA;EACA;EACA;EAEA;EAEA;EACA;;;AAGD;EACC;EACA;;ACbA;EDWD;IAKE;;;;AEhBF;EACC;EACA;;;AAGD;EACC,WC0BgB;;;ADvBjB;EACC;EACA;EACA;EAEA;EAEA,aCakB;EDZlB;EACA,aCgBkB;EDflB;EAEA;EACA;;;AAGD;EACC;EACA;EAEA;EACA;EACA;EACA,cCiBQ;EDhBR,eCgBQ;;;ADbT;EACC;EAEA,aA1CsB;;;AEEvB;EACI;EAEA;EACA,aD+Be;;AC7Bf;EACI;;AAGJ;EACI;;;AAIR;EACI;EACA;EACA;EACA;EACA;EACA;;;AAGJ;EACI;;;AAOJ;EACI;;;AAGJ;EACI;EAEA;;;AAOJ;EACI;;;AAGJ;EACI,SArDW;EAuDX,aDtBe;ECuBf;EACA;EACA;EAEA;EACA;;;AAGJ;EACI;EAEA,SDXK;ECaL;;;AAIJ;EACI,aDzCe;;;AC6CnB;EACI,aD/Ce;;;ACmDnB;EACI;EAEA;;;AAGJ;AAAA;AAAA;EAGI;EACA,cDxCK;;;AEtDT;EACI;EACA;EACA;;AACA;EACI;;;AAIR;EACI;EACA;;;AAIJ;EACI;EAEA,YFoCK;;;AG9CT;EACC;EACA,eAVkB;EAYlB;EACA,aH0BgB;;;AGvBjB;EACC,YAhBe;EAiBf,eAhBkB;EAkBlB;EACA,aHmBgB;;;AGhBjB;EACC,YAtBe;EAuBf,eAtBkB;EAwBlB;EACA,aHYgB;;;AGTjB;EACC,YA5Be;EA6Bf,eA5BkB;EA8BlB;EACA,aHKgB;;;AIzCjB;EACC;EAEA;EACA;EAEA;;;ACLD;EACC;IACC;;EAGD;IACC;;;AAQF;EACC;AAAA;IAEC;;;AClBF;EACC;EAEA;;;AAGD;EACC;EACA,YN0CQ;EMzCR;;;AAGD;EACC;EACA;EAEA;EACA,SNmCQ;EMjCR;EAEA;EACA;;;AAGD;EACC;EACA,cN4BQ;EM1BR;EACA;;;AAGD;EACC;EACA;EACA,KNgBQ;;;AOpDT;EACC;EACA;EACA;EAEA,aP+CQ;EO9CR,gBP8CQ;;AFjDR;ESHD;IASE;;;;ACTF;EACC;EACA;EACA;EACA;EAEA;EACA;EACA,eR4CQ;;AFjDR;EUHD;IAWE;IAEA;IACA,eRqCO;;;;AQjCT;EACC;EACA;EACA;EACA;EACA;;AVpBA;EUeD;IAQE;IACA;IACA;;;;AAIF;EACC;EAEA;;;AAGD;EACC;EACA;EACA;EAEA;EACA,SRQQ;EQNR,aRJuB;EQMvB;EAEA;;AAEA;EACC;EACA;;;AAIF;EACC,cRVQ;;;AS9CT;EACC;;;AAGD;EACC,OAPkB;EAQlB;;AXNA;EWID;IAKE,OAZe;;;;AAgBjB;EACC;EAEA;;;AAGD;EACC;EAEA;;AAEA;EACC;;AAGD;EACC;;;AChCF;EACC;EACG,SV8CK;EU7CL;EACA;EACH,gBV2CQ;;;AUxCT;EACC;EACG;EACH;EACG;EAEA;EACH;EACG;EAEA;;AAEA;EACI;EACA;;;AAIR;EACI,cVqBK;;;AUlBT;EACI;EACH;;;AAGD;EACC;;AAEG;EACI;EACA;;;ACxCR;EACC;EACA;EAEA,aXwDS;EWvDT,gBXqDS;;;AWlDV;EACC;;AAEA;EACC,eXqCO;;;AYjDT;EACC,YZsDQ;;;AYnDT;EACC;EACA;;;AAGD;EACC;EACA;EACA;EACA;EACA;EACA,SZoCQ;EYnCR;EACA;EACA;;AAEA;EACC,eZ+BO;;AY5BR;EACC;EACA;;AAGD;EACC;;Ad3BD;EcMD;IAyBE,SZuBQ;;;;AYnBV;EACC;;;AAGD;EACC;;;AAGD;EACC;EACA;;;AAGD;EACC;;;AAGD;EACC;EACA;EAEA;EAEA;;AAEA;EACC;EACA;EACA;EACA;EACA;EACA;;AAGD;EACC;EACA;EAEA;;;AAIF;EACC;;;AAGD;EACC,YZ/BQ;;;AYkCT;EACC;;;ACzFD;EACC;EACA;EACA,Kb6CQ;Ea5CR;EACA;EAEA;;;AAGD;EACC;;;AAGD;EACC;;;AAGD;EACC;EACA;EACA;EACA;EACA;;;ACvBD;EACC,edwDS","file":"styles.css"} \ No newline at end of file +{"version":3,"sourceRoot":"","sources":["../../src/styles/basic/_color-themes.scss","../../src/styles/basic/_fonts.scss","../../src/styles/basic/_typography.scss","../../src/styles/basic/_global.scss","../../src/styles/_mixins-and-functions.scss","../../src/styles/basic/_layout.scss","../../src/styles/_variables.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","../../src/styles/components/_about-blog.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;;;AC5BD;EACC;EACA;EACA;EACA;EACA;;AAKD;EACC;EACA;EACA;EACA;EACA;;AAKD;EACC;EACA;EACA;EACA;EACA;;ACpBD;EACC;EACA;EACA;EACA;EACA;EACA;;;ACTD;EACC;EACA;EAEA;EACA;EACA;EAEA;EAEA;EACA;;;AAGD;EACC;EACA;;ACbA;EDWD;IAKE;;;;AEhBF;EACC;EACA;;;AAGD;EACC,WC0BgB;;;ADvBjB;EACC;EACA;EACA;EAEA;EAEA,aCakB;EDZlB;EACA,aCgBkB;EDflB;EAEA;EACA;;;AAGD;EACC;EACA;EAEA;EACA;EACA;EACA,cCiBQ;EDhBR,eCgBQ;;;ADbT;EACC;EAEA,aA1CsB;;;AEEvB;EACI;EAEA;EACA,aD+Be;;AC7Bf;EACI;;AAGJ;EACI;;;AAIR;EACI;EACA;EACA;EACA;EACA;EACA;;;AAGJ;EACI;;;AAOJ;EACI;;;AAGJ;EACI;EAEA;;;AAOJ;EACI;;;AAGJ;EACI,SArDW;EAuDX,aDtBe;ECuBf;EACA;EACA;EAEA;EACA;;;AAGJ;EACI;EAEA,SDXK;ECaL;;;AAIJ;EACI,aDzCe;;;AC6CnB;EACI,aD/Ce;;;ACmDnB;EACI;EAEA;;;AAGJ;AAAA;AAAA;EAGI;EACA,cDxCK;;;AEtDT;EACC;EACA;EACA;;AAEA;EACC;;;AAIF;EACC;EACA;;;ACJD;EACC;EACA,eAVkB;EAYlB;EACA,aH0BgB;;;AGvBjB;EACC,YAhBe;EAiBf,eAhBkB;EAkBlB;EACA,aHmBgB;;;AGhBjB;EACC,YAtBe;EAuBf,eAtBkB;EAwBlB;EACA,aHYgB;;;AGTjB;EACC,YA5Be;EA6Bf,eA5BkB;EA8BlB;EACA,aHKgB;;;AIzCjB;EACC;EAEA;EACA;EAEA;;;ACLD;EACC;IACC;;EAGD;IACC;;;AAQF;EACC;AAAA;IAEC;;;AClBF;EACC;EAEA;;;AAGD;EACC;EACA,YN0CQ;EMzCR;;;AAGD;EACC;EACA;EAEA;EACA,SNmCQ;EMjCR;EAEA;EACA;;;AAGD;EACC;EACA,cN4BQ;EM1BR;EACA;;;AAGD;EACC;EACA;EACA,KNgBQ;;;AOpDT;EACC;EACA;EACA;EAEA,aP+CQ;EO9CR,gBP8CQ;;AFjDR;ESHD;IASE;;;;ACTF;EACC;EACA;EACA;EACA;EAEA;EACA;EACA,eR4CQ;;AFjDR;EUHD;IAWE;IAEA;IACA,eRqCO;;;;AQjCT;EACC;EACA;EACA;EACA;EACA;;AVpBA;EUeD;IAQE;IACA;IACA;;;;AAIF;EACC;EAEA;;;AAGD;EACC;EACA;EACA;EAEA;EACA,SRQQ;EQNR,aRJuB;EQMvB;EAEA;;AAEA;EACC;EACA;;;AAIF;EACC,cRVQ;;;AS9CT;EACC;;;AAGD;EACC,OAPkB;EAQlB;;AXNA;EWID;IAKE,OAZe;;;;AAgBjB;EACC;EAEA;;;AAGD;EACC;EAEA;;AAEA;EACC;;AAGD;EACC;;;AChCF;EACC;EACG,SV8CK;EU7CL;EACA;EACH,gBV2CQ;;;AUxCT;EACC;EACG;EACH;EACG;EAEA;EACH;EACG;EAEA;;AAEA;EACI;EACA;;;AAIR;EACI,cVqBK;;;AUlBT;EACI;EACH;;;AAGD;EACC;;AAEG;EACI;EACA;;;ACxCR;EACC;EACA;EAEA,aXwDS;EWvDT,gBXqDS;;;AWlDV;EACC;;AAEA;EACC,eXqCO;;;AYjDT;EACC;EACA;EAEA;EACA,KZ+CQ;;;AY5CT;EACC,YZ8CQ;EY7CR,eZ2CQ;;;AYxCT;EACC;EACA;;AdZA;EcUD;IAKE;;;;AAIF;EACC;EACA;EACA;EACA;EAEA;EACA,SZsBQ;EYrBR,KZqBQ;EYnBR;EACA;EACA;;AAEA;EACC;EACA;;AAGD;EACC;;AdvCD;EcmBD;IAwBE,SZWQ;;;;AYPV;EACC;EACA;;;AAGD;EACC;;;AAGD;EACC;EACA;;;AAGD;AAAA;EAEC;;;AAGD;AAAA;EAEC;EACA;EAEA;EAEA;;AAEA;AAAA;EACC;EACA;EACA;EACA;EACA;EACA;;AAGD;AAAA;EACC;EACA;EAEA;;;AAIF;EACC;;;AAGD;EACC;;;ACpGD;EACC;EACA;EAEA,Kb4CQ;Ea3CR;EAEA;;;AAGD;EACC;;;AAGD;EACC,ebmCQ;;;AahCT;EACC;EAEA;EACA;EAEA;EACA;;;ACzBD;EACC,edwDS","file":"styles.css"} \ No newline at end of file