Digital accessibility 2/3 - Checklist for accessible websites

An accessible internet is crucial for everyone to be able to participate fully in digital life. So: What can we do to make websites accessible for everyone? "How to create an accessible website?" 

From design and content to technical implementation, there are many ways to achieve this. The catalog is long and you can and must do a lot. And of course, it can be really complicated in places. That's exactly why it's worth getting started. 

tl;dr

• Accessible websites are important for everyone to participate in digital life.
• Designers, developers and editors can work together to achieve accessibility.
• Designers can use clear structures and pay attention to good design.
• Editors should create clear and comprehensible texts and provide alternative texts for images.
• Developers can use suitable HTML, CSS and ARIA tags to ensure that the website is accessible.
• Regular testing is important to ensure and improve accessibility.
• It is important to consider accessibility from the outset and to work on it continuously.

Barrier-free design

Designers play a crucial role in the development of accessible websites. They can ensure that the design is appealing and accessible at the same time. Accessibility does not mean that the design has to suffer. On the contrary, a well-crafted design can improve the user experience and usability for all. Designers can use clear structures, choose fonts that are easy to read, pay attention to contrasts and colors, etc. In addition, they can also communicate with users to better understand their needs and incorporate them into the design.

Color and contrast

• Note and check the contrast between text and background color (AA Large text: 4.5:1 , Small text: 3:1).
• Checking is required for text and graphics that are important for understanding the website.
• The contrast should also not be too strong, e.g. on a white background you should use a slightly lightened black
• The understanding of content should never depend solely on color coding.

Font

• The font contains all required weights, e.g. Regular, Bold, Italic
• The font contains all required characters and special characters.
  e.g. "ß"
• Choose a clear and legible font that works in large & small text sizes.
• The individual characters should not be too wide or too narrow.
• The line width should not be too thin or too thick, i.e. avoid fine and bold typefaces.
• The line width of the individual characters should not vary too much.
• All characters should stand out from each other and be clearly recognizable.

Typography

• The font should be large enough to be easy to read (at least 16px, but this depends very much on the font chosen).
• The lines of continuous text should not be too long or too short so that they are easy to read (approx. between 45 and 75 characters per line).
• The line height should be easy to read (not too little or too much space between the lines).
• Headings should stand out from the body text by size, style or color.
• Important or longer content should not be written in capitals or italics.

Media

• Graphics should have captions.
• Do not use a graphic as the only means of understanding content.
• Icons should ideally be informative and not just serve as decoration.
• The meaning of the icons should be common.
• Do not make the text background transparent or darken the image under the text if the text is on an image.
• Animations should not run too fast or flicker.
• There should be a pause button for animations, moving images or audio.
• Audio or video content should not start on its own.

Layout and hierarchies

• Important content is easy to recognize and easy to read.
• Content is well structured and divided into hierarchies.
• The reading order should be observed.
• Create spacing between the individual elements in a visually pleasing ratio, e.g. no excessive spacing in lists or between individual modules on the page.

Accessible content

Editors can also keep a few things in mind when creating accessible web content. They can help to ensure that the information is accessible to all users by using clear and comprehensible texts. This includes using simple and easy-to-understand language and structuring the content with meaningful headings and paragraphs. There are also ways to reduce barriers when using images, videos or audio.

Text

• The use of H1 to H6 headings helps to clearly structure the page and enable intuitive navigation.
• By using meaningful text as links, it is clear to all users where the link leads and what information they can expect.
• Short and clearly formulated titles and introductory texts make it easier for users to quickly grasp the content of the page and find their way around.
• Provide content in plain language or easy language.

Media

• Do not forget the old texts.
• Create text and audio alternatives for video and audio content, e.g. subtitles or audio description for video, transcript for audio

Structure

• Create a clear and logical page structure
• Choose meaningful page titles
• Create subpages with "easy language" and "sign language". 

Accessible code

Devs hold an important lever when it comes to website accessibility. Many people rely on technical assistance systems such as screen readers or keyboard navigation to use a website. That's why the technical foundations are also crucial to making a website accessible. This starts with HTML or the page layout and does not end with testing. Here are a few things that developers should pay attention to:

Semantic HTML

• The most important and most underestimated part. Use the right element for each use case. Example: div button, div headline

Page Layout

• Correct content structure of the page in header, nav, main, aside, footer etc.
• Skiplinks for repeating elements (bypass).

ARIA

• ARIA stands for "Accessible Rich Internet Applications"
• Extra markup for specific cases.
• The first rule of ARIA: do not use if an equivalent native HTML is available.

CSS

• Use relative units for text and layout so that everything scales when the font size is changed.
• Use media queries for Reduced Motion.

Text 

• Good structure is important: headlines in the correct hierarchy, text in paragraphs, list elements, etc.

Media

• Text alternatives for non-decorative images 
• Transcripts for video and audio files

• Alternative options for other media forms, e.g. a video instead of a virtual tour 
• Avoid automatic animations or make them stoppable (reduced motion)

Testing

• Examine the code with linting tools or w3c validator and find potential accessibility problems at an early stage and make appropriate adjustments.
• Use browser plugins for testing (Google Lighthouse, Axe-Tools, plugins that simulate certain disabilities such as hand weakness/trembling or visual impairments)
• Use system tools from the browser and OS and test the page (larger font, more contrast, reduced animations, dark mode, magnification tools, etc.)
• Test website with keyboard navigation and screen reader desktop and mobile.

All right, now what?

The good news is that there are a few measures that are easier to implement than others. These include

• Alternative texts for images can be maintained directly by editors in most CMSs
• Structure texts and set meaningful titles for links
• Adjustments to the CSS for more contrast or larger fonts are quite easy to implement with a small audit

For other measures, however, more lead time is required. You have to go deeper into the code, revise content or even create it from scratch.

• Subtitles for videos
• Videos with sign language
• Contributions in easy language
• ARIA tags for ease of use with assistance systems

In the best case scenario, accessibility is not simply retrofitted, but considered and implemented right from the start. Accessibility is not something that has to be done once and then it will work for the future. The law "after the launch is before the launch" also applies here. So it's also about structures and processes. You can and should do that:

• Seek help and advice (preferably not just legal advice)
• Do an audit
• Do user testing
• Do training in your company
• Take a look at the topic of plain language
• Talk about it and show others what you have done

Extra: Accessible CMS

Let's move away from the website and the user's perspective. Because behind most websites is a content management system. Editors use CMS to maintain content on the website, create landing pages, manage articles, etc. The CMS backend is basically just a website or app, so accessibility naturally plays a role here too and the same rules apply to accessibility as for a website (the front end)

When it comes to CMS, accessibility is a somewhat more complex issue. There is no one CMS that meets all requirements. Some come with accessibility features out of the box, while others can be enhanced with extensions and plugins.

But fortunately, there are also special guidelines from the W3C for "Authoring Tools Accessibility" (ATAG), which are intended to ensure that the tools for creating content are accessible to as many users as possible.

These guidelines are divided into two parts: Guideline A provides instructions for the accessible design of authoring tools. Guideline B specifies that functions must be available to support the creation of accessible content. However, this is not only about CMS, but also about other types of tools such as photo editing. 

CMS are software products that are regularly developed further. It is therefore worth taking a close look at what they do for accessibility and how this changes. Popular CMSs such as Wordpress and Drupal or even Wix have solid accessibility features for editors. However, popular CMSs in Germany such as Typo3 or Magnolia do not perform as well in terms of accessibility. The situation is different for products from the USA.

We prefer modern CMS such as Webflow or Strapi. Webflow is practically the more modern Wordpress and offers solid functions in both areas. It performs particularly well in Guideline B of the ATAG. It has a self-commitment to accessibility and has been successfully tested by blind people with screen readers.

Strapi is an open-source, self-hostable headless CMS in which the frontend and backend are better separated. The backend is used exclusively for data maintenance and is therefore clear and clean. In the frontend, you have full control over the accessibility functions, and Strapi also has a self-commitment to accessibility. Both are therefore well suited to creating websites in a tool that is as accessible as possible and is also accessible itself.

PS: Under the keyword "accessibility" you will find a collection of projects here on the website with a major focus on this very topic.

Click here for part 1 of the series: "The absolute basics". Part 3 will follow soon.