Accessibility issues caused by web developers

As mentioned above, screen readers read out all the information on a page. In order to read text in the correct language (with the correct pronunciation), it is important for the page to have the correct language code.

When navigating with a keyboard, you will quickly find that it is quite annoying: navigation is linear - from top to bottom, from left to right – which means that you have to go through a lot of repetitive content (header, menu items) at the beginning of each page before the main content can be reached.

To avoid this, it is important to ensure that one of the first elements on the page is a "Skip to main content" link, which, when clicked, moves the focus (both the keyboard and screen reader focus) to the beginning of the content section of the page.

The link can also be hidden until the user moves the focus to it. There is a common myth that the skip link is used only by the blind, and therefore can be invisible. But in fact, it is also used by viewers, and therefore, it is important that when the link is focused, it becomes visible and, when activated, it actually works.

The focus of the keyboard and screen reader differs in that the keyboard can only navigate along clickable elements, but the screen reader can navigate along all elements of the webpage (including headings, pictures, texts). Controlling the focus with scripts comes into play when the focus order of the keyboard or screen reader on the page needs to be corrected.

If using simple semantic HTML, without manipulating the order of elements with scripts or styles, then there is probably no need to control the focus of the keyboard or screen reader. In general, however, there are certain places where manipulation is required to keep the focus order logical.

All elements that can be clicked with the mouse must also be focusable with the keyboard. It is recommended to always present interactive things with semantic elements such as <a>, <button>, <input> etc. Non-semantic elements such as <div> are not clickable by nature and therefore cannot be focused with the keyboard (Tab key).

If there are elements on the page that are not interactive by nature, but must be clickable, then they must be added to the focus sequence using the tabindex attribute. Tabindex can have different values.

For screen readers, voice commands, and other assistive technologies, it is important to ensure that elements which are presented with an icon or image have a text alternative available in code.

If the image is presented with an <img> element, a text alternative is added through the alt="Image description..." attribute. For other elements (different icons, close button with “X”), the aria-label="Image description..." attribute is used.

If no alt attribute is added to the image, the screen reader reads out the image’s file name, which is almost never informative. If you leave the alt attribute blank, the screen reader will not read that picture out at all – this is good for decorative images, such as background photos, which rarely convey important additional information.

When it comes to clickable icons, then without alternative texts, screen reader users will simply not know what they do. However, not every icon requires an alternative. For example, if there is also the word "Print" next to the printer icon, then the icon does not provide additional information and therefore does not require a text alternative.

There are also rules for writing the text alternatives – they must be specific and convey the same meaning as the picture/icon itself. For example, the alternative to an envelope icon should probably be "E-mail" or "Send message" rather than "Envelope".

Definitely avoid words such as “picture”, “link”, “click” when writing alternative text, and don’t fill the alternative texts with file names or random text strings. View examples and tips for writing alt texts.

It often happens that several links that lead to the same page are placed next to each other. For example, an icon and text, or a news article image, title, and "Read more" are all separate links that lead to the same page. This means that keyboard or screen reader users must make 3 clicks instead of 1 to move over each news article.

Status messages, such as error or success messages, search box states ("Please wait...", "34 results found", "No results found"...), how far something has loaded, how much time is left to confirm the transaction, etc., must be automatically read out by the screen reader, without actually moving onto the messages.

To make the screen reader read something automatically, the aria-live or role attributes can be used. When you use these attributes on an element, the screen reader responds to changes that occur within that element.

Therefore, to automatically read an error message, the container with the aria-live or role attribute must already exist on the page when it is loaded. Then, when you insert the error message into the container through a script, the screen reader will read it out loud.