Quick win checklist for web accessibility

I was recently asked if we had a list of the most important and easiest ways to make a website as accessible as possible. Specifically, tasks that can be applied quickly, without discussion with the developer, the designer, or the client. Quick Wins for Accessibility! What simple changes make a big impact? In this blog post, I will introduce the topic, explain the basics and why accessibility is so relevant, and then provide a quick win checklist to sum it all up.

There are some basic rules, for the accessibility of websites, first listed here and then explained afterward:

• Use and build HTML in a semantically correct fashion

• Add descriptive text for screen readers to content that is not already described by text and is not just used as a visual decoration

• Hide purely decorative elements for screen readers

• Ensure keyboard usability and set focus recognizably

People who are unable to easily grasp websites due to an impairment often use screen readers to enable them to navigate their way online. A screen reader is a standalone application or a browser add-on that is already integrated into the operating system. It converts the information available on the screen into natural language and reads it out to the user. On a web page, the HTML structure and its content are used by the screen reader to identify the presented content.

Native HTML is already accessible. Components such as buttons, links, labels, or form fields are already recognizable to screen readers and read out accordingly. This makes our work as developers easier. However, the situation is different for custom widgets, which the screen reader cannot recognize without additional information. Screen readers also have keyboard shortcuts, for example, to jump over all links on a page or to navigate through all headings.

You can think of a screen reader as a sort of record player needle, only recognizing and playing back exactly what is directly below it. Elements without text or further recognition options cannot be read aloud and remain incomprehensible or completely inaccessible to users with special needs.

< You can think of a screen reader as a sort of record player needle, only recognizing and playing back exactly what is directly below it. Elements without text or further recognition options cannot be read aloud and remain incomprehensible or completely inaccessible to users with special needs. >

creen reader website elements can be divided into two types: those that are visually visible and those that remain hidden. For example, elements that contain additional information text already been visually displayed elsewhere should remain hidden.

Content exclusive to screen readers can be visually hidden using CSS so that the DOM structure is preserved and thus readable by the screen reader. The Accessibility Developer Guide suggests the following class for this purpose:

.visually-hidden {

position: absolute;

left: -10000px;

top: auto;

width: 1px;

height: 1px;

overflow: hidden;

}

This way, elements are displayed outside the screen and as small as possible. If you now set the padding to 0 and the margins to -1, you can even create an element with dimension 0x0 while still being contained in the DOM structure.

When talking about screen readers and accessibility, the term WAI-ARIA often comes up. WAI-ARIA stands for Web Accessibility Initiative - Accessible Rich Internet Applications and aims to create a web standard that makes web pages more accessible and understandable for screen readers.

Content that is not useful for the screen reader, such as when it only serves as decoration, should be hidden because it provides unnecessary information for screen reader users. This includes icons, single characters, or unknown abbreviations. It is important, however, to provide an understandable alternative for the omitted areas so that no information is omitted.

The attribute aria-hidden="true" can be used to hide individual tags and all their connected elements from screen readers.

In order not to get lost in a sea of text, it is important that the focus always remains visible. This means that if the focus styles applied individually by browsers are overwritten, they must still be clearly visible in all new stylings. For example, if the focus is removed from an element with a blur edit, it should be set again immediately, otherwise, you will end up in a blank space when navigating the site. If absolutely necessary, the tab index of the corresponding elements can be adjusted. However, the page layout and its HTML structure should be constructed in such a way that that is not necessary.

The following suggestions are quick ways to increase user accessibility on websites. This checklist does not claim to be complete or absolute. We’d be happy to email hidden; JavaScript is required with any suggestions or additions!

Developers should answer the following questions with a yes in order to make their websites more accessible:

• Do buttons and links have meaningful text?

• Are clickable elements displayed as buttons and not as links?

• Are links used only to connect pages or as anchors?

• Are input fields linked to their labels?

• Do all content-relevant elements have descriptive text?

• Have titles been chosen or added in a meaningful way?

• Are heading tags structured correctly?

• Are native HTML components used when custom widgets are not necessary?

• Does the specified language in the <html> tag match the text’s language?

• Is the navigation at the top of the page and is there an anchor link that can jump directly to the page’s content?

• Can all functions be accessed using only the keyboard?

• Is the focus recognizable at all times?

To get an initial overview of how accessible a website is, browser plugins such as WAVE can help. Such tools can quickly find the existing deficiencies and list them.

Developers can also try completely dispensing the styling of a website to evaluate to what extent the page is still usable. Does everything still work? Is it still possible to navigate everywhere? Are there any labelless components?

Something that is often overlooked is the pure keyboard usability and the concept focus. Ask the following questions:

• Is the website operable with only a keyboard?

• Can all necessary elements be reached?

• Does the navigation follow the course of the page or does it jump back and forth illogically?

Everyone benefits from these small improvements, not just users with screen readers. All developers relate to the statement: Beautiful code is more readable and therefore easier to maintain. However, not only developers gain from this, but also all users, “normal” and those with screen readers. The importance becomes especially obvious when the internet connection is limited, styles cannot be loaded, or old devices or browsers are used. Also, in poor visibility or sunlight, users benefit from optimized contrast.

Making a website accessible with screen readers is only one part of digital accessibility. There are many more ways that are not only visual, but also related to motor, cognitive, or auditory senses/impairmen

The following websites have consistently helped me in my work to make web applications more accessible:

• Ire Aderinokun’s Blog bitsofcode and her Accessibility Cheatsheet [https://bitsofco.de/the-accessibility-cheatsheet/]

• a11y with Lindsey [www.a11ywithlindsey.com]

• Accessibility-Developer-Guide [www.accessibility-developer-guide.com]

• Mozilla’s page about accessibility [https://developer.mozilla.org/en-US/docs/Web/Accessibility]

• both articles by Manuel Matuzovic on Medium about CSS and JavaScript

  • https://medium.com/@matuzo/writing-css-with-accessibility-in-mind-8514a0007939

  • https://medium.com/@matuzo/writing-javascript-with-accessibility-in-mind-a1f6a5f467b9

I've been working on this topic for about a year and a half now. It all started with a ticket that said the application should be "AA compliant". At that time I just knew that images have an alt attribute and that you should pay attention to colors.

Article by Christina da Silva