Accessibility and Its Practical Impact on Screen Reader Users

The intention of this document is to provide insight into why it is important to create websites, internal systems, content management systems, applications and documents in an accessible way. It includes an explanation of the mandatory accessibility criteria according to the Web Content Accessibility Guidelines 2.1 standard, as this version is currently implemented in European legislation.

The document is divided into 11 chapters by the type of structural elements of the website, as well as web or mobile applications. The same principles can be implemented without any problems in creating of components for internal information systems.

Keyboard and Linear Movement

When a sighted person looks at a webpage, they can so to say scan it. One glance is enough to see its layout – where the menu, search field, header, main content or footer is. Users with severe visual impairments access apps, websites and documents through assistive technologies. The most common is magnification software and screen readers, which convert any information presented graphically into speech.

Completely blind people, of course, cannot use a mouse because they cannot see the cursor and they navigate the web and documents principally by using the keyboard. For this reason, it is absolutely essential that all the elements available to a sighted user when the mouse is clicked are fully accessible and controllable from the keyboard.

The use of screen readers has two major pitfalls:

• Screen reader presents information to its user as it follows in the code, and it ignores styling using CSS altogether. This means that although a web site or application is clear to sighted (and sometimes to partially sighted) users, it can cause big problems for blind people.
• Screen readers approach digital content in a linear form and they always capture just a certain small section. When moving the Tabulator, the user gets to all interactive elements; moving the arrow keys, they are able to read a maximum of 1 line at a time. However, in addition to the standard navigation keys, the user can also make use of the special keyboard shortcuts integrated in whichever screen reader, which can skip much larger sections. Such accelerated browsing is called quick navigation.
  How does keyboard accessibility work? The Tab key should take the user to each link on the page. After pressing the Enter key, the link should activate. They can use the arrow keys to move around the page with ease and the space bar to select checkboxes, radio buttons, and other form elements.

(<a href=https://www.w3.org/TR/WCAG21/#keyboard-accessible“>WCAG Guideline 2.1 Keyboard Accessible)

Focus Order

The goal is to ensure that users can navigate through content in a logical order and operate it using the keyboard. This reduces confusion because users can form a consistent mental model of the content.

Different orders can reflect logical relationships, such as navigating a table by rows or columns.
The default reading order is determined by the order of elements in the DOM (Document Object Model, which is the structure of the webpage’s content). The navigation order of focusable elements (elements that can receive keyboard focus) MUST be logical and intuitive.
Focusable elements include links, form inputs and controls, buttons, and any element with a tabindex value of 0 or greater. Use the tab key to navigate forward through focusable elements and shift + tab to navigate backward. This is the first step to determine if a site is accessible for all users.

The Tabindex Attribute

The tabindex attribute of 1+ explicitly defines the navigation order for focusable elements (typically links and form controls) within a page. It can also be used to define whether elements should be focusable or not.
Values of tabindex:

• Tabindex=“0“ – indicates that the element should be placed in the default navigation order.
• Tabindex=“-1“ – removes interactive elements from the default navigation flow. In most cases, this would not be desirable. If added to something that is not already interactive, tabindex=“-1″ allows that element to receive programmatic focus. This means focus can be set to it using focus() scripting. This may be useful for elements that should not be navigated to directly using the Tab key but need to have keyboard focus set to them. Examples include a modal dialog window that should be focused when it is opened
• tabindex=“1″ (or any number greater than 1) defines an explicit tab or keyboard navigation order. This must always be avoided.

(WCAG success criterion 2.4.3: Focus Order – level A)

Page Areas

These are labels for specific parts (sections) of a website or web application and most often they define the header, navigation, main menu and footer. They are identified using HTML or ARIA tags.
In order to maintain clarity and quick navigation, care must be taken to use the areas sparingly and not have too many of them on the site or application.

Entry of the Most Frequently Used Areas Using HTML and ARIA Tags

(WCAG Success criterion 1.3.1: Info and Relationships – level A, 2.4.1: Bypass Blocks – level A)

Skip Links

Skip link can help either screen reader users who do not support area navigation or keyboard users regardless of disability to skip the header and navigation and jump directly to the main content or from the footer to the top of the webpage. We place the first skip link just before the header as the very first element. Another one can be placed under the footer to allow returning to the header area.
They can take several forms:

• Visible – we place plain text with a link on the page. This is the simplest way, but this link will be visible to all users at all times.
• Partially hidden – if we are concerned about the aesthetic appearance of the skip link, we can hide it until the user navigates to it using the keyboard. For such a link to be useful and accessible, it must:
  • be hidden by default,
  • be accessible via the keyboard,
  • be sufficiently highlighted when it receives focus,
  • ensure that the correct main area or header receives focus. It is not enough for the page to visually scroll.

Do not hide links using CSS display:none or set the hidden attribute. Both methods would completely disable the link.
When naming the link, we base it on its purpose:

• Skip to content – a link leading to the beginning of the main area.
• Skip to navigation – a link leading to the menu.
• Up – returns the user to the header area.

On most websites, having 2 skip links is sufficient: „Skip to content“ and „Up.“ It is also important that the links are translated into the language of the website. If the website is in Slovak, the skip links must be in Slovak as well. If it is in Czech, then translated into Czech.

Heading Structure

It is still the most used method of movement on the web. The screen reader allows you to jump forwards and backwards through headings in general, but also through individual levels (valid for NVDA). Therefore, we recommend not to underestimate the heading outline on websites, applications and documents.

Principles for Creating Heading Outlines

• A heading outline is similar to chapter numbering in a professional publication, so it must be logical and must not skip levels. A level 1 heading <h1> indicates the title of the page or states the main content. It is most often the title of an article or subpage. The other headings should follow logically so that the structure makes sense. That’s why we don’t skip levels – a level 1 heading is followed by a level 2 heading, and so on.
• Even though WCAG allows it and it is therefore not a violation of accessibility, we recommend that there should always be only one level 1 heading on a page. Either it is the title of the site, subpage, or article. In that case, it lists the main area.
• Always create headings on the site using HTML tags <h1> to <h6> and not just in a bigger and bold font. The visual styling of headings is not important for blind users because screen readers ignore it. However, if we don’t create a heading outline using HTML, the user won’t know that there are any headings at all.
• In MS Word and in content management systems (such as WordPress), we use styles to create headings. The way to create them depends on the particular system.
• We do not use headings to highlight blocks of text. In this case, we use bold and/or enlarged font.
• Care should also be taken to ensure that headings are suitably adapted for partially sighted users. Italic, overly decorative calligraphy-like, strikethrough, cursive and handwriting-like fonts are inappropriate.
• They need to be visually separated by font size and thickness, and possibly also by color. We pay attention to the correct contrast – up to 18 pt 4,5:1, above 18 pt at least 3:1.

(WCAG Success Criterion 2.4.6: Headings and labels – level AA)

Links

They are a key part of websites and mobile applications in particular and redirect the user to a subpage or another website.
A screen reader (NVDA) user can use the navigation through the web and web applications to navigate through links of any kind – all of the visited or unvisited ones. Therefore, their appearance is very important for people with total or partial sight loss.
Screen readers also offer a so-called list of elements where the user can filter the type of elements – headings, links, fields, forms and so on.

Highlighting an Untargeted and Focused Link

A common way to distinguish plain text from link text is to underline and change the color. Thus, the link text is underlined and mostly blue. Care should be taken when selecting the color of links:

• The contrast between the background and the color of the link,
• The contrast between the color of the plain text and the color of the link.
• The link should also change if the user hovers over it with the mouse cursor or via the keyboard. This is done either by making the underline thicker and changing its color, or by framing it from above and below and changing its background.

Reachability of the Link from the Keyboard

Most people use a mouse to move around a web page. However, there are groups of users who cannot use it for a variety of reasons – blind people, people with low vision, people with physical disabilities (even temporarily e.g. a broken arm), users with severe motor impairments or laptop users who find it impractical to use the touchpad. It is therefore important that links are also accessible from the keyboard.

Legibility of the Link Placeholder Text

The placeholder text is the text that introduces the link. That is, not https://www.technologiebezzraku.sk, but Technologies Without Sight.
This text should itself clearly and distinctly convey where the link is going without the user having to read the text around it. So, let’s avoid links like „Here“, “Read more”, „More here“, „More information here“, „As he writes“, „He said“ and so on. Why?
A screen reader user often uses the movement of so-called elements, which include links, to move around the web. If he comes across a link with the placeholder text „Here“, they don’t know what it refers to. This forces them to read the content around the link to orientate themselves and find the context of the unintelligibly named link.
Also, if we use a link to external documents that require another application to open (e.g. pdf), it is useful to point this out in the text of the link.

Example of correct and Incorrect Worded Links

Some links are too long and we cannot use them from a visual point of view. For such cases, it is possible to use a description via the aria-label tag for a small number of links, ensuring that intact users only see the short form of the link (e.g. „More information“), but screen reader users have the opportunity to hear a much longer description („More information about the Accessible 2023 conference“).
This is because if we use the aria-label, only the screen reader takes information from it. It remains visually hidden. However, care must be taken to ensure that the beginning of the description via the aria-label is identical to the visually visible link. Otherwise, users relying on the screen reader will not be able to access the links.
The purpose of this technique is to provide a label for objects that can be read by an assistive technology. The aria-label attribute provides the text label for an object, such as a button or link. When a screen reader encounters the object, the aria-label text is read so that the user will know what it is.
(WCAG Success Criterion 1.1.1: Non-text Content – level A)

In the case of a large number of links, it is preferable to bind them with visible text that describes them in more detail, for example with the heading of the article using the aria-labelledby tag.
(WCAG Success Criterion 2.4.4: Link Purpose in Context – level A)

Forms

Forms are a common feature on websites and the screen reader user can also use them to navigate through elements such as edit boxes, buttons, toggles, radio buttons, check boxes, select boxes and so on. Therefore, it is also crucial that they are not only accessible but also fully controllable from the keyboard.

Principles for creating accessible forms

• Each form element must be controllable and accessible from the keyboard – use native HTML forms controls, because they are accessible by default. (WCAG Guideline 2.1: Keyboard accessible – level A)
• Identify the input purpose. If the user enters a name, the edit field will be a text. If an email address, the email type. This eliminates data entry errors. (WCAG Success Criterion 1.3.5 Identify Input Purpose – level AA)
• Top align labels for input fields: For visually impaired users who use zoom, positioning the labels above the input field means they won’t have to horizontally scroll across the page to complete every form field.
• Edit fields must be bound to their label – set the identifier in the <input> to correspond with the for attribute of the <label>. It’s best not to nest <input> inside of <label> as some assistive technologies won’t support it.
• Use hint text, not placeholder text. Placeholder text disappears once the information has been entered into a field, making it more difficult for a user to remember the hint and to make a correction. Also, it might be completely inaccessible to some users, because placeholder text is not broadly supported across assistive technologies and not displayed in older web browsers. The default color of placeholder is a pale grey, meaning it has poor color contrast against most background colors.
• Highlight elements on focus. Clearly highlight <input> on focus and ensure the color chosen to highlight has sufficient color contrast against the background color. It is useful for users, who use keyboard only. (WCAG success criterion 2.4.7 Focus Visible – level AA)
• Style and write errors correctly. Don’t just rely on color, use a concise and clear textual alternative to describe the error. For screen readers, use the aria-invalid=“true attribute. To associate any inline errors with form fields, use aria-describedby. (WCAG success criterion 3.3.1: Error identification – level A, 3.3.3: Error Suggestion – level AA, 1.4.1: Use of Color – level A)
• Identify a required fields (WCAG success criterion 1.3.1: Info and Relationships – level A, 3.3.2: Labels or Instructions – level A)
• Label related fields in a group with fieldset and legend (WCAG success criterion 1.3.1: Info and Relationships – level A)

The example of simple accessible form

Modal Dialog

A dialog is a window overlaid on either the primary window, or another dialog window. Windows under a modal dialog are inert.

Unaccessible Modal Dialog

Problems for screen reader, magnification software and keyboard users:

1. Modal dialog is in the end of the code.
2. Users cannot use the keyboard to detect that a modal dialog has appeared.
3. The modal dialog is pass-through, the screen reader users doesn’t know which elements belong in it and which don’t.
4. The modal dialog does not have options to close it from the keyboard – the close button or the Escape key.
5. The font in the modal dialogue is too small, the contrast against the background is minimal.
6. After the modal dialog is closed, the focus is not on the element from which the modal dialog was invoked.

Accessible Modal Dialog

1. The modal dialog behaves like a newly loaded web subpage.
2. The focus is on the first element of the modal dialog, usually the Close button.
3. The modal dialog starts with the heading <h1> and the headings outline is consistent. Don’t skip heading levels. (WCAG success criterion 1.3.1)
4. Every element in the modal dialog is reachable and controllable from the keyboard:
   • Tab and Shift+Tab – moves the focus to the next or previous focusable element inside the dialog. When focus is on the first or last focusable element in the dialog, moves focus to the first or last focusable element in the dialog.
   • Esc – closes the modal dialog. (WCAG Guideline WCAG Guideline 2.1 Keyboard Accessible)
5. The font in the modal dialogue must be legible, large enough (at least 12 pt is recommended), footer-less font.
6. The modal dialogue must have a sufficiently contrasting background to the site. It is good practice to gray out the site content and leave only the modal dialog visible. (WCAG Success Criterion 1.4.3: Contrast minimum – level AA)
7. To make the content easier to read when displayed on small screens, the dialog fills 100 % of the screen. Completely covering the background window also hides background movement that occurs on some mobile devices when scrolling content inside the dialog.
8. When the modal dialog is closed, the focus returns to the element from which the dialog was invoked. (WCAG Success Criterion 2.4.3: Focus order – level A)

Graphic

Images are an integral part of websites, apps, and many documents. An explanation of how to make a proper description of them would be worth a separate publication.

In general, if an image carries key information without which the content cannot be understood, we need to give it what is called an alternative description. We do this by using the alt=““ attribute. If there is a text in the image, the alternative description includes the full transcript, which also applies to screenshots. Here we give consideration to whether it is necessary to use images with text at all. For example, if it’s an invitation with the date and time on it, it’s difficult for intact users to work with such an image.

If the image is also a link or a button, we do not describe it, but include its function in the alternative description: instead of describing the appearance as alt=“magnifying glass“, we include alt=“Search“. Or if the logo at the beginning of the site is used to return to the home page, we give it the description „alt=“Back to home page“.

For infographics, graphs and charts, we just add a generic alternative description to the images, but ensure that people can get to the information from them in other ways. We can either compile the results from the graph and chart into an accessible table or summarize them in text. For example, we will transcribe the entire text of the infographic into a separate text document.

If the graphic is merely decorative – illustrative images from photo libraries to „beautify“ the text – we do not add alternative text to it. The alt=““ attribute must remain, but we leave it empty.

It is recommended to describe the image as you would describe it to a person who does not have access to it, for example on a phone. While there is no strict length limit on the length of alternative text, it is advisable to be as clear and concise as possible. It is impossible to move around in such text and the user must either listen to the whole text or skip the image.

As far as images for test problems are concerned, we place the alternative description as text to the images, not in the alt attribute. This is because most of the time it is necessary to work with such images and this gives the solver the possibility to read the description in parts.

Context is also very important. Let’s illustrate this with an example of an image with a logo. We choose a different description in the case of a logo placed on the web and a different one when we write about a new logo in an article.

Example of using the alternative text

Tables

Tables display information arranged in a grid with a relationship to either the first cell of a column or a row, or both.

It is because of this logical relationship that it is not permissible from an accessibility point of view to create tables that are only visually indicated. Therefore, we will use functions to create the table, or we will define the table using tags in the HTML code.

Another essential thing is to avoid merged cells in a row. In order for a table to be truly accessible, it needs to be regular.
Column and row headers are important for the sake of the screen reader user not losing context. If we are using color to highlight information, it is also essential to find another way to differentiate it. This is not only for the sake of blind users, but also for the sake of people suffering from color blindness. These can be different symbols, the meaning of which we will explain in the legend.

Tables in HTML

We can create accessible tables in HTML. However, there are a few guidelines to follow:

1. If we want to assign an alternative description to a table, we define it using the <caption> tag and place it right below/after the <table> tag. This is especially useful when moving between tables.
2. A very important point, as we’ve pointed out several times, is defining column and row headers.
   • For the column headers use the <th scope=“col“>
   • For the row headers <th scope=“row“>
   • For the data cells <td>
3. Instead of absolute size, we use proportional size setting. This is especially important for partially sighted users. This will allow the cells to get larger and smaller as the reader needs.
   (WCAG success criterion 1.3.1: Info and Relationships – level A)

Lists

If the list is properly constructed, it has several advantages for screen reader users.

The screen reader informs the user that the list is following and how many items it has. In addition to moving through lists, it is also possible to navigate through its individual items. If the user is not interested in the list, he can easily skip it with one keyboard shortcut.

It is recommended using lists in the <nav> landmark and grouping all related links in it. We can also use it in the footer, for example, to group social networks or contact information.

Properties of a Properly Created List

• It is created using <ul> or <ol> tags and not just visually by CSS. We will use the list style in text editors and editorial systems.
• A group of related information belongs in one multi-item list, not several single-item lists.
  (WCAG success criterion 1.3.1: Info and relationships – level A)

Graphic Design of the Content

Text

1. Contrast of the font with the background:
   • Font up to 18 pt – 4,5:1
   • Font over 18 pt – 3:1 (Black font against a white background has a contrast of 22 to 1, so the color range to maintain the correct contrast is very wide. )
   • Text that is part of a logo or brand name has no contrast requirement. (WCAG Success Criterion 1.4.3: Contrast minimum – level AA)
2. Resize text – text can be resized without assistive technology up to 200 percent without loss of content or functionality. (WCAG success criterion 1.4.4: Resize Text)
3. Text spacing – there is no loss of clarity if the user sets the values of the following parameters to a maximum of these values:
   • Line height (line spacing) to at least 1.5 times the font size,
   • Spacing following paragraphs to at least 2 times the font size,
   • Letter spacing (tracking) to at least 0.12 times the font size and,
   • Word spacing to at least 0.16 times the font size.
     (WCAG success criterion 1.4.12: Text spacing – level AA)
4. Font: size between 12-15 pt, not italicized, underlined or strikethrough, do not capitalize words. Screen readers spell capitalized words. Visually impaired users find such text difficult to read. A handwritten or calligraphic-style font can also be difficult to read.
5. Left alignment is generally best for text, as justified alignment can create large gaps between words.
6. It is not possible to rely on color as the sole highlighting of important information, like e.g. in a chart, diagram, map, text or links. Important information needs to be highlighted in other alternative ways that are accessible to color blind, partially sighted and blind people who cannot rely on color recognition. (WCAG success criterion 1.4.1: Use of color – level A)

Contrast of Non-textual Elements

In the following a contrast has to have a ratio of at least 3:1 against adjacent color(s):

• User Interface Components,
• Visual information required to identify user interface components and states, except for inactive components or where the appearance of the component is determined by the user agent and not modified by an author,
• Graphical Objects,
• Parts of graphics required to understand the content, except when a particular presentation of graphics is essential to the information being conveyed.

What does it mean?
The intent of this is to ensure that active user interface components (i.e., controls) and meaningful graphics are distinguishable by people with moderately low vision. Low contrast controls are more difficult to perceive and may be completely missed by people with a visual impairment. Similarly, if a graphic is needed to understand the content or functionality of the webpage then it should be perceivable by people with low vision or other impairments without the need for contrast-enhancing assistive technology.

Of course, low contrast is not conducive to good readability in direct sunlight or harsh artificial lighting, for example. Therefore, even an intact user benefits from proper contrast, whether of text or non-text elements.
(WCAG success criterion 1.4.11: Non-text Contrast – level AA)

Multimedia Content Accessibility

Background Multimedia Content

If any audio on a Web page plays automatically for more than 3 seconds, either a mechanism is available to pause or stop the audio, or a mechanism is available to control audio volume independently from the overall system volume level.

This is for three reasons:

1. A deaf or hard of hearing persons may not hear the background audio, thereby exposing themselves to an uncomfortable social situation.
2. The user of a screen reader (software that converts graphical information into spoken language) may not be able to navigate a site with unstoppable audio. It is very distracting for them.
3. For a user who suffers from attention deficit disorder, background audio can also be very distracting.

It is much preferable to run any multimedia content only at the user’s initiative. (WCAG success criterion 1.4.2: Audio Control – level A)

Captions and Audio Description

The pre-recorded video or audio must be accompanied by:

1. Subtitles for hearing impaired persons who have lost their hearing during their lifetime.
2. Audio description for people who are blind that comments on what is happening in the scene during silent sections or when only music is playing and the blind viewer is unable to perceive the action.

Also captions and audio description are provided for all live audio content in synchronized media.
What tools and techniques are currently (in 2024) being used for transcription or captioning, and how audio description production is evolving, can be found in the webinars. Links are at the end of the document.
(WCAG Guideline 1.2: Time-based Media)

Flashing Content

Web pages do not contain anything that flashes more than three times in any one second period, or the flash is below the general flash and red flash thresholds.

All content on the Web page must meet this success criterion, because any content that does not meet this can interfere with a user’s ability to use the whole page.

The intent is to allow users to access the full content of a site without inducing seizures due to photosensitivity.
Individuals who have photosensitive seizure disorders can have a seizure triggered by content that flashes at certain frequencies for more than a few flashes. People are even more sensitive to red flashing than to other colors, so a special test is provided for saturated red flashing.

Flashing can be caused by the display, the computer rendering the image or by the content being rendered. The author has no control of the first two. They can be addressed by the design and speed of the display and computer. The intent of this criterion is to ensure that flicker that violates the flash thresholds is not caused by the content itself. For example, the content could contain a video clip or animated image of a series of strobe flashes, or close-ups of rapid-fire explosions.
(WCAG success criterion 2.3.1: Three Flashes or Below Threshold – level A)

Conclusion

Digital accessibility means equal (not the same) access to information for all users of websites, applications of all kinds, and documents without a difference. However, we are not just talking about accessibility only to comply with legal requirements, as of the European Union or of individual countries.

In fact, the requirements for making digital content accessible are based on the very needs of users with disabilities to be able to access information at all.

Why is it important to make digital products accessible? Why do users need well-defined page areas, heading structure, correctly named form elements, descriptions of key images? And how to do it? The document offers answers to these questions both from the perspective of the Web Content Accessibility Guidelines standard and from the perspective of the everyday user of assistive technologies themselves.

Sources

• Accesibility MDN
• The Anatomy of Accessible Forms: Required Form Fields
• Web content Accessibility Guidelines 2.1
• Patterns (ARIA Authoring Practices Guide – APG)
• WCAG 2.1 Techniques: Examples of ways to meet WCAG
• Michaela Dlhá: Prístupnosť
• Screen Reader User Survey #10 Results
• Technické nástroje a pracovní postupy pro titulkování a přepis – záznam webináře z 13. 2. 2024
• Slova, která malují: Audio popis ve filmovém světě (záznam webináře z 2. 6. 2024)
• Reading Order/Focus Order