Basic accessibility errors when developing a site
Greetings This article will discuss the most common mistakes of webmasters in terms of accessibility for screen reader users. I, being myself such a user, will try to describe the main problems of inaccessibility of sites and how to solve them.
I would like to immediately emphasize that this article does not pretend to any standard, is not a direct guide to action, and also contains only the most common, but equally critical accessibility errors when creating a site.
The most common mistake of many webmasters is the disuse of the alt = "" attribute in the <img /> tag or its incorrect use.
If at least to specify the attribute somehow accustomed to the requirements of search engines, then very few people know how to specify correctly. Below are examples of illiterate attribute content:
')
As the most logical to use this attribute, let’s look at an example.
Suppose that you have a list of users on your site, the name of each is displayed in front of each avatar. Also suppose that in the list of users three users came across with the name “Igor”. If an ordinary user among the Igor's find the right one by avatar, then the user of the screen access program cannot determine by the same name as the desired one.
In this case, each avatar in the alt = "" attribute will display the first name with the user's last name. Thus, from the point of view of graphic display, nothing will change, and a blind visitor will be able to find the right person.
Everyone knows the title tags from <h1> to <h6>. I think it is logical that they should be used for headlines, and not for changing the font size, but there are also such smart people.
In the screen reader, you can set the length of the string, usually the default is 100 characters.
When the characters in the header is more than one hundred, the screen reader throws the remainder to a new line.
Thus, when you press the down arrow on a too long headline, the program is voiced on two lines of “Heading Level 1-6”.
On many sites, including some domain name registrars, they like to indicate the prices for service renewals in the tooltip when you hover the mouse. I'm not saying that this is a bad tactic, but it is worth thinking about the availability of these tips for all customers.
The solution is very simple, it’s enough to use the title = "" attribute for links, but not to use scripts.
Note: there is unverified information that the title attribute is not voiced on tablets, but the article deals primarily with screen access programs for Windows: Jaws and NVDA.
I do not know who is still using tabular layout, but it’s still worth refusing if you want to make your resource convenient for the blind and visually impaired.
The main errors when using tables:
It is better to refuse nesting of tables at all, and to use the <th> attribute in tables with quotations, with a list of terms, and not just for beauty.
Probably the most famous of accessibility are roles and labels.
The role = "" attribute is usually written in <div> blocks, but with the advent of HTML5, the need to assign roles to blocks has disappeared.
The table provides a list of roles and replacement tags from HTML5.
As can be seen from the table, in HTML5 there is no alternative tag for the role of “search”, or I don’t know it.
If the site contains several different menus, search fields, all with the same role, and if everyone signs in plain text, there can be visually too much information.
In this case, the area-label = "" attribute helps out.
In this attribute, you can specify any information for the user of the screen access program, which will help him orient himself among homogeneous areas.
An important addition: you should not immediately assign roles and labels to all areas of the site, it terribly difficult to navigate.
As for me, for example, the role of the “banner” generally only gets in the way, since everyone understands that there is a cap on top and not a basement.
Finally I would like to touch on the topic of captcha.
Thanks to special plug-ins and add-ons, the modern screen reader user should not have problems passing protection against robots in the following cases:
If the picture with the code without the alt attribute, or the protection is a puzzle, or the picture is sewn into the site design and the characters are generated directly on the background, then the blind visitor will not be able to send the form himself.
I tried to describe the main errors, because of which sites may be of little access for screen reader users. I hope that this article will help someone in creating an accessible site.
If someone still has any questions, I will gladly try to answer them in the comments.
I would like to immediately emphasize that this article does not pretend to any standard, is not a direct guide to action, and also contains only the most common, but equally critical accessibility errors when creating a site.
Pictures and attribute ALT
The most common mistake of many webmasters is the disuse of the alt = "" attribute in the <img /> tag or its incorrect use.
If at least to specify the attribute somehow accustomed to the requirements of search engines, then very few people know how to specify correctly. Below are examples of illiterate attribute content:
')
- Using the same word for different pictures (alt = "image");
- Using a non-meaningful character set (alt = "dsf86sdfgbvc94nf56");
- Duplicate the page title;
- Placement in the attribute of the whole sentence, phrases;
- The indication in the attribute of one letter, often not even the first letter of the name of the object in the image.
As the most logical to use this attribute, let’s look at an example.
Suppose that you have a list of users on your site, the name of each is displayed in front of each avatar. Also suppose that in the list of users three users came across with the name “Igor”. If an ordinary user among the Igor's find the right one by avatar, then the user of the screen access program cannot determine by the same name as the desired one.
In this case, each avatar in the alt = "" attribute will display the first name with the user's last name. Thus, from the point of view of graphic display, nothing will change, and a blind visitor will be able to find the right person.
Headlines
Everyone knows the title tags from <h1> to <h6>. I think it is logical that they should be used for headlines, and not for changing the font size, but there are also such smart people.
In the screen reader, you can set the length of the string, usually the default is 100 characters.
When the characters in the header is more than one hundred, the screen reader throws the remainder to a new line.
Thus, when you press the down arrow on a too long headline, the program is voiced on two lines of “Heading Level 1-6”.
Tooltips
On many sites, including some domain name registrars, they like to indicate the prices for service renewals in the tooltip when you hover the mouse. I'm not saying that this is a bad tactic, but it is worth thinking about the availability of these tips for all customers.
The solution is very simple, it’s enough to use the title = "" attribute for links, but not to use scripts.
Note: there is unverified information that the title attribute is not voiced on tablets, but the article deals primarily with screen access programs for Windows: Jaws and NVDA.
Tables and spreadsheet
I do not know who is still using tabular layout, but it’s still worth refusing if you want to make your resource convenient for the blind and visually impaired.
The main errors when using tables:
- Nesting of one or several tables into another makes navigation very difficult, since the screen reader reads the coordinates of each cell;
- Use the <th> tag where it is not required. An example would be the script games "Ogame", "2moons", "Supernova" and the like;
It is better to refuse nesting of tables at all, and to use the <th> attribute in tables with quotations, with a list of terms, and not just for beauty.
Roles and tags
Probably the most famous of accessibility are roles and labels.
The role = "" attribute is usually written in <div> blocks, but with the advent of HTML5, the need to assign roles to blocks has disappeared.
The table provides a list of roles and replacement tags from HTML5.
| Role | Replacement tag | Presentation by a screen reader |
|---|---|---|
| banner | <header> | Banner landmark |
| navigation | <nav> | Navigation landmark |
| main | <main> | Main landmark |
| complementary | <aside> | Additional landmark |
| contentinfo | <footer> | Content Reference Information |
| search | - | Search landmark |
As can be seen from the table, in HTML5 there is no alternative tag for the role of “search”, or I don’t know it.
If the site contains several different menus, search fields, all with the same role, and if everyone signs in plain text, there can be visually too much information.
In this case, the area-label = "" attribute helps out.
In this attribute, you can specify any information for the user of the screen access program, which will help him orient himself among homogeneous areas.
An important addition: you should not immediately assign roles and labels to all areas of the site, it terribly difficult to navigate.
As for me, for example, the role of the “banner” generally only gets in the way, since everyone understands that there is a cap on top and not a basement.
Captcha
Finally I would like to touch on the topic of captcha.
Thanks to special plug-ins and add-ons, the modern screen reader user should not have problems passing protection against robots in the following cases:
- captcha is represented by a textual arithmetic example asking for an answer;
- The form uses the Google Recaptcha widget, in which you just need to check the box;
- if a graphic image is used, then it should have an alt attribute, preferably alt = “captcha” or alt = “image with code”.
If the picture with the code without the alt attribute, or the protection is a puzzle, or the picture is sewn into the site design and the characters are generated directly on the background, then the blind visitor will not be able to send the form himself.
That's all
I tried to describe the main errors, because of which sites may be of little access for screen reader users. I hope that this article will help someone in creating an accessible site.
If someone still has any questions, I will gladly try to answer them in the comments.
Source: https://habr.com/ru/post/335352/
All Articles