Blog | 09 July 2020

Accessibility part 3: Labeling your content

The final blog post in our series on the Web Accessibility Directive is about how to label content and tell what's what in different situations. There are several simple things you can do yourself.

In our two previous blog posts, you have been able to read about the Web Accessibility Directive, which comes into force as a law on September 23, 2020, and how you can avoid simple errors by using Sitevision's built-in features. The Accessibility Directive is very much about how you label content and tell people what's what in different situations. This blog post is intended to help you further. There are a number of simple things you can do yourself, without the need for a consultant.

There are also a number of free services you can use to check accessibility in different ways in your environments. We'll take a deeper look at some of the features of Sitevision and then look at where more information can be found.

Bild på person vid dator i kontorslandskap.

Facilitating the visitor by marking up content in forms

The guidelines suggest that you should help your users fill in input fields in forms. This is done by indicating what type of content is expected in the different fields. Browsers or assistive technologies can then sometimes automatically suggest an input. The values that appear are based on, for example, previous entries in fields of the same type. This may include the visitor's name, email address or postal address.

This is a built-in function in our form modules. It's easy to link fill-in support to the questions you ask. We call this field names in Sitevision and each question you ask can be linked to a different field name. When a visitor has previously filled out a form with the same question types, the browser will remember and suggest values in the next form.

Language and nonstandard language on a page

In WCAG2.1, you can read that if you are developing content for a website, you can increase the likelihood that screen readers and other assistive technologies will present the content correctly if you specify in the HTML code what language the content is written in. This should be done using a lang attribute. This has long been the standard in Sitevision. The lang attribute is added automatically linked to which language your website is set to be in. However, sometimes you may need to add text in a different language. For example, your website is set to Swedish, and your content is written in Swedish. But then you need to add a quote to your page, written in English. This should also be marked up in the code with a lang attribute. By selecting the part of the text that differs, you can then choose to indicate which language the text/piece is by inserting language.

Specify the role of different parts using element types and ARIA roles

You are expected to specify in code the role of the different elements of the page. The reason for this is to increase the chance that the information on your page is presented correctly, regardless of the tool the visitor is using. If the content is correctly labeled, the visitor can navigate between the different parts of the page in a standardised way.

There is a basic rule to follow here: use the different elements of the HTML language as much as possible and supplement with WAI-ARIA when the element types are not sufficient. WAI-ARIA allows you to express in text what is not clear from the coding, but there are also default values you can enter.

It may sound difficult, but this is also supported by Sitevision. Some functions linked to the aria roles are already correctly specified in their template code, others you need to set out yourself. Here we list the element types and aria roles that should be considered mandatory, and therefore should also be included in your structure.

Header, Footer, Nav and Main element types

Labeling which parts of your environment are header, footer, menu and main content using the HTML language element types Header, Footer, Nav and Main also indicates in the code what roles those objects have.

Many times you have a basic template in your structure and it is usually possible to add these element types. Is your page header in its own grid? Then you specify on the grid that it belongs to the Header element type and so on. You may need help here, and if you don't have anyone to ask, you can always contact us for some guidance.

Aria role Search

Aria roles are seen as complementary to element types and are only added when needed. For example, the search function on your website doesn't have a corresponding element type, so you mark up the search function with the Search aria role instead.

Find out more about the aria roles on our help website. External link.

What tools are available?

The Directive is clearly documented and described by DIGG, which is also the supervisory authority responsible for controls. They have a thematic website webbriktlinjer.se External link. which provides clear and accessible checklists and information on all aspects of the Directive.

There are also a range of online services, often free of charge, where you can test accessibility in different ways. Different browsers offer different plug-ins for testing, and this is of course something you should do at an early stage.

However, don't forget to do some simple tests of your own. Can the content be zoomed in without it being wrong or ugly? Do voice services work, something many of you already have installed on your own computer? Is it possible to tab through menus and content? Is the text written in plain language? Test in different browsers and make sure it works well. Does the structure feel logical? Have someone test the environment and solve a problem. What will the experience of your website be like if you imagine you can't see the images or read the text set against a background color?

Accessibility requires thought, patience and a lot of work, but at the end of the day, it goes without saying that everyone should be able to access your information. Isn't that right?

Book a demo