The author's version of the text is published here
Accessibility: what it is, who needs it, and how to provide it
How does a person interact with the world around them? First, they receive information through various sensory organs, then they process it, acknowledge it—and only then do they begin to interact with the environment. It's important to remember this mechanism if you're trying to guarantee digital accessibility. Ask yourself, "Can any person receive the information on my site, understand it and interact with it?"
The visual sensory channel isn't the only way that we receive information. What's more, it isn't always the primary one. A person receives information through the five main sense organs: the eyes (sight), ears (audition), tongue (taste), nose (smell), skin (touch, pain, temperature change). Today, the digital world allows us to use, at the very least, sight, audition, and touch.
When you are testing to see whether your interface can be perceived, understood, and interacted with, think about the following:
- Deaf and hard-of-hearing people have difficulty perceiving or don't perceive audio content at all. One alternative might be subtitles, transcriptions, or sign language translation. In addition, Deaf people cannot interact with an organization through phone calls; therefore, it is important to offer the opportunity to communicate via email, chat, or other text-based forms of communication.
- Blind people don't see your interface, but they perceive content through hearing, with the help of screen readers, or touch, using a Braille display.
- Partially sighted people have difficulty perceiving design that doesn't account for their specific needs.
- People with motor challenges cannot always use a mouse, so they need the ability to use your site without a mouse (using a keyboard) and see the element they are interacting with on the screen.
For all of us, it is important to understand not merely how to avoid mistakes but how to correct them as well.
It is far simpler to guarantee accessibility in the digital world than in the physical. Unlike building a ramp, which may be difficult to install due to a building being a historical monument or the land for the ramp not belonging to you, everything in the digital world depends on two people: the designer and the developer. All these specialists need is to know how to guarantee and provide accessibility. It's worth noting that in order to do this, you don't have to make any special or separate versions of your content. All you need is a single, universal and accessible version for all the aforementioned categories of people. In order to develop a site that meets accessibility requirements, you can reference WCAG 2.2 and GOSTR 52872-2019 (in Russia). Here are the requirements included in these standards that a designer and developer must meet.
What the designer needs to know
A designer is the one who lays the cornerstones of accessibility on a site. They are the person who should provide for all the possible alternatives for perceiving content. For example, a designer should understand that a Blind person can't follow a scenario with a captcha, which means that other user checks should be made available. Still, technical capabilities should be discussed with the developer.
Accessibility begins with good structure. Structured content is important to everyone, both people with disabilities and without.
- Good navigation allows you to show a person what can be found and done on the site. For instance, the BBC website has several levels of headlines and headings that represent the architecture of the site.
The first level of headlines on the BBC website: News, Sport, Reel, More. The next level of headers within News are Home, Coronavirus, Video, and so on
- Headings aid in navigation within a single page.
On the left is unbroken text without headings; on the right is a text structured with headings (source: Kalbag, L. ACCESSIBILITY FOR EVERYONE).
- Text that is structured in points is easier to read.
On the left is an unbroken, unstructured text; on the right is a text structured with points (source: Kalbag, L. ACCESSIBILITY FOR EVERYONE).
- If you aren't writing for a professional community, use simple, easily understandable language without special terminology.
- Avoid jargon, abbreviations, and idioms.
- The recommended line length for a single-column text is 45–75 characters and 40–50 characters for text in two or more columns.
- W3C recommends using at least 18pt regular or 14pt bold fonts.
- Typography is most important for people with dyslexia. Use sans serif fonts. According to Dyslexic.com, some relatively "good" fonts are Arial, Trebuchet MS, Myriad Pro и Geneva.
- Text on the page should magnify to 200% using Cmd - + or Ctrl - + without using assistive technologies. It's important that the page size adapts to screen size and remains both readable and functional.
On the left is a portion of the Garage site at standard size; on the right, it is enlarged.
- Wherever possible, avoid using text in images, as the quality can decrease when enlarged. If you do choose to do this, make sure that the picture has alt-text for Blind users.
In the international WCAG 2.2 accessibility standard, there is no requirement or even recommendation for special versions of a site. However, there is a guideline for the contrast between the text and its background: 4.5:1. However, for text that is at least 18 pt regular or 14 pt bold in size, the contrast can be reduced to 3:1. Contrast is not just important for blind and partially sighted people; a high-contrast interface is important to all users and is a vital usability factor.
- All non-decorative elements should meet the aforementioned requirements, and more accurately, they should be high-contrast. It is important to remember that even very bright colors can be low-contrast relative to particular backgrounds, such as grey on grey.
Not an exception.
The contrast of the text from left to right: 1.6:1, 1.4:1, 3.6:1
- People with difficulties perceiving colors might not see what you want to highlight using color. Ensure that you use additional tools for displaying information or navigation: icons, text, and so on.
Only color is used to highlight a mistake
There are additional tools used to inform users of a mistake
Link states: inactive, active, visited.
- A user should have the ability to distinguish a link from unclickable content. In order to ensure this, the designer can apply a standard pattern of underlining text. It is also worth using other means of highlighting to allow the user to recognize a link.
- The link text should make it clear what will happen after the user clicks on it. For example, "On my channel "Not an Exception," I talk about inclusive design." If I just leave the link address, https://t.me/neiskluchenie, a Blind person will have to guess what the link is about since a screen reader will simply read out the link's characters. For a seeing person, it's just visual trash. Don't use a simple address or the text "click here": they don't help users.
- One best practice: change the color of already-visited links.
Situations may occur in which a person cannot take in audio information. The reason may be anything from deafness or a foreign language to a loud environment or the inability to raise the volume (even if the content demands it). In all of these situations, it is important to offer tools for the alternative presentation of audio content.
- A transcript is one best practice for presenting audio information in text format.
On the Post-Science [Postnauka] website, videos have transcripts
- An equally common tool is subtitling. It is essential that a person can read not only speech, but information about contextually relevant sounds like a knock at the door.
- Blind people do not see pictures, but with the help of the "alt" attribute, you can describe what they depict. It is important that the content of that attribute communicate information that would actually help a person imagine the image. Don't use filenames or generic text like "photo.jpg," “DSCF0017.jpg,” or “City.”
- Aside from the design itself, the developer should have:
- Captions for links that are presented as buttons.
- Text that describes images so that the information can be made accessible to Blind people.
- The captions for clickable elements and texts for images must contain only essential information, be short and not begin with the words “This picture shows…” or “Clicking on this link will take you to…”.
Bad: alt = “Little Secrets. Keyhole”
Good: alt = “We can see people through a keyhole.”
The fewer animated or auto-playing elements there are on your site, the easier it will be to make it accessible. If you do use animation, make sure that the content is accessible to any user and ensure that they have time to take it in. Animated elements should also not interfere with site navigation.
- Make sure that there are instructions and hints that will help the user avoid mistakes. One best practice is to use a mask on each field that suggests the format in which users need to enter information. For example, a person might not know whether they need to put a + in front of the country code when entering their phone number. Make sure that all elements are clearly named.
On the Garage site, form fields have labels, and the phone number field uses a mask. Required fields are also noted.
- Make sure that there are instructions that help users fix mistakes.
- One good practice is to highlight the element that is missing the correct information.
- When interacting with a mobile device, it’s important to make it easy for users to tap elements on your site. Make your touch targets no less than 44 CSS pixels. This will make it easy for an average adult user to hit them with a finger. Since icons are typically smaller, you need to increase the touch target around them.
Elements might be smaller than 10mm, but the touch target around them should not be smaller than 10mm.
What the developer should know
Blind people use accessibility programs, or screen readers, to interact with mobile devices. The program looks at the code and reads out everything that sighted people can see on the screen. In order for a screen reader to process content, the code should be written correctly and meet accessibility requirements. Proper code helps you avoid creating barriers for the Blind.
- Headings help Blind people navigate around a page. Unlike sighted people, who can distinguish between font sizes, you can help Blind people using headings in code. For example, if heading levels h1 and h2 are correctly placed in the code, a person can read through the first level, choose the section they want to read, and then move on to the next level.
- The reading order should be the same as on the visual site: left to right and top to bottom. This way, the first thing that a screen reader user hears should be the first element on the page. There are exceptions, however: for instance, in order to simplify the process of filling out a multi-page form, it makes more sense to direct their focus to the next field rather than to the form name that comes first on every page.
- Any interface element with which a user can interact should include the element type, its state (value), name, and any necessary hints in its code. This allows users to understand the element before them, how to interact with it and what will eventually happen. As a rule, the types of native elements are correctly identified by default.
- If an element is of no value to a user, you should make it “invisible” to the screen reader. Otherwise, you may overload users with unnecessary information about the technical aspects of the interface.
- Make sure that the interface can be operated without using a mouse and that when using a keyboard, the focus can be directed to and removed from any component of the page without getting stuck on it. It’s important that when switching focus to another element, data entry and interaction with a field or navigation element should not change any content so as not to confuse the user.
- For sighted people, the focus position on the page is important when operating from the keyboard.
The development process for accessible interfaces
Failure to account for accessibility at the very beginning of the digital development process can have the same consequences as in the physical world. If you don’t begin by ensuring that the entrance to a building is at the same level as the street, you’ll have to build a ramp. The same applies to digital development: by ignoring accessibility from the outset, you may end up in a situation where you will need to come up with all kinds of “crutches” quickly.
One good practice is to have designers and developers check in to see what design solutions will be easiest to realize from an accessibility perspective. Experience has shown that such solutions ultimately turn out to be more usable for people with and without disabilities.
Don’t forget: after your interface is ready, you should conduct self-testing and usability tests with the help of people with disabilities.