What is WCAG? Digital accessibility in practice

What is WCAG? Digital accessibility in practice

You may have heard of WCAG, but do you know what it means in practice for your business and digital solutions?

WCAG is about digital accessibility – in other words, making websites, online stores, apps and self-service solutions easy to use for the people they are designed for.

For some users, digital accessibility is essential. This may include people who use screen readers, have impaired vision, cannot use a mouse or need particularly clear instructions. However, many other people also encounter situations where accessibility makes a noticeable difference. They may be watching a video without sound, using their phone while on the move or dealing with a temporary injury that makes it more difficult to navigate as usual. 

WCAG provides an important framework for making digital solutions easier to use for more people. However, the term is often mentioned alongside technical standards and legislation, which can make it difficult to understand what actually applies. 

What Is WCAG?

WCAG stands for Web Content Accessibility Guidelines and is an international set of guidelines describing how digital content can be made more accessible for people with different needs. 

The guidelines were developed by W3C, the organisation behind a number of key web standards, including CSS and XML. WCAG is used as a technical framework when designing, developing, creating content for and testing websites, apps and other digital solutions. 

WCAG is not Danish legislation in itself. However, the guidelines play a central role in the standards and requirements applied in Denmark and across the EU. WCAG is therefore relevant both for public organisations, businesses with products or services that may be subject to specific accessibility requirements, and businesses that generally want to create a more user-friendly digital solution. 

The Three Levels of WCAG

WCAG is divided into three levels: A, AA and AAA. The levels build on one another. This means that a solution that meets level AA must also meet the requirements at level A. 

• Level A is the basic level. It focuses on removing some of the most serious barriers that could otherwise make content or functionality completely inaccessible. This may include ensuring that informative images have a text alternative, that core functions can be used with a keyboard, that form fields have clear labels, and that pre-recorded video with audio has captions. 
• Level AA builds on level A and is the level most organisations work towards in practice. It includes additional requirements relating to contrast, navigation, text enlargement, focus indication, forms and the overall usability of content and functionality. 
• Level AAA is the highest level. It introduces further requirements relating to, among other things, readability and assistance for users. The level may be relevant in selected areas, but is generally neither a realistic nor necessary target for an entire website. 

For public websites and mobile apps, levels A and AA are central to the applicable requirements. For private businesses, the specific requirements depend on the individual product or service. 

Who Is Covered by Digital Accessibility Requirements? 

Digital accessibility requirements do not apply in the same way to everyone. It is therefore important to distinguish between public websites and apps and private businesses. 

Public Websites and Mobile Apps 

The Danish Web Accessibility Act entered into force in 2018, and the requirements were subsequently phased in over several years: 

• New public websites published after 22 September 2018 became subject to the requirements from 23 September 2019. 
• Existing public websites became subject to the requirements from 23 September 2020. 
• Public mobile apps became subject to the requirements from 23 June 2021. 

The Danish Web Accessibility Act generally applies to the websites and mobile apps of public authorities and organizations governed by public law. This may include municipalities, regions, ministries and certain educational institutions.

They must meet the relevant digital accessibility requirements and publish an accessibility statement for every website and mobile app covered by the rules.

Private Businesses and Consumer Services 

Private businesses are not generally covered by the Danish Web Accessibility Act. However, from 28 June 2025, specific accessibility requirements have applied to selected products and services provided to consumers. 

The rules stem from the EU Accessibility Act, also known as the European Accessibility Act, and have been implemented in Denmark through the Danish Accessibility Act. 

This may, for example, be relevant for businesses that provide: 

• e-commerce services
• consumer banking services
• television and streaming services
• e-books and digital reading solutions
• certain digital services within passenger transport
• other selected digital services for consumers 

The key factor is therefore not simply whether a business has a website. It depends on what the business offers and whether the product or service is provided to private consumers. 

Products and services supplied solely on a B2B basis are generally not covered by the Danish Accessibility Act. There are also specific exemptions, including exemptions for micro-enterprises. It should therefore always be assessed on a case-by-case basis whether a particular solution is covered. 

WCAG, EN 301 549 and Legislation: What Is the Difference? 

The terms WCAG, EN 301 549 and legislation are often used interchangeably. They are connected, but they do not mean the same thing. 

WCAG is therefore the underlying technical framework. EN 301 549 is the broader European standard that is used, among other things, to assess public websites and apps. Legislation then determines who is covered and which obligations apply. 

For a standard website, a large part of the work will relate to WCAG. However, if the solution also includes PDFs, video, apps, booking systems, self-service functionality, payment solutions or customer service, there may be additional aspects to consider. 

WCAG Principles in Practice 

WCAG is based on four core principles. These are often referred to as POUR, as the English terms are Perceivable, Operable, Understandable and Robust. 

Perceivable 

Content must be perceivable by users in different ways. Important information must not depend solely on one sense or one particular way of using a solution. 

In practice, this means, among other things:  

• Informative images must have relevant text alternatives so that the content can also be conveyed by a screen reader. 
• Decorative images should not normally interfere with screen reader users. 
• Text must have sufficient contrast against the background. 
• Colour must not be the only way important information is conveyed. For example, an error message should not only be marked in red but should also be explained with text or an icon. 
• Pre-recorded video with important audio should have captions so that the content can also be understood without sound. 

Operable

Users must be able to operate the solution in different ways. This includes people who cannot use a mouse, use a keyboard or rely on assistive technologies such as voice control. 

In practice, this means, among other things:  

• Navigation, menus, buttons and forms must be usable with a keyboard. 
• It must be clear where the focus is when moving through a page. 
• Focus must follow a logical order. 
• Dialog boxes, pop-up windows and menus must be able to be opened, used and closed without a mouse. 
• Time-based or moving content must be possible to control, pause or stop where relevant. 

Understandable 

Content, navigation and functionality must be easy to understand. Users should be able to work out what is happening and what the next step is. 

In practice, this means, among other things:  

• Headings, buttons and link texts must be clear and descriptive.
• Form fields must have clear labels and relevant instructions.
• Error messages must explain what is wrong and how the user can proceed. 
• Navigation and core functionality must behave consistently across the solution.
• Content must be written clearly and structured in a way that makes it easier for users to find their way around. 

Robust  

The solution must be built in a way that makes it usable across browsers, devices and assistive technologies.

In practice, this means, among other things:  

• Semantic HTML should be used as the starting point.
• Headings, lists, tables and form fields must be marked up correctly.
• Interactive elements must have a name, role and status that assistive technologies can understand.
• Screen readers must be able to convey core functionality and changes to content. 
• ARIA should be used carefully and not as a replacement for correct HTML.

WCAG Versions at a Glance

WCAG has been developed continuously as the internet and the use of digital solutions have evolved. 

• WCAG 1.0 was published in 1999 and focused primarily on early websites and the most basic accessibility issues.
• WCAG 2.0 was published in 2008 and introduced the POUR principles as well as the structure of guidelines and success criteria that is still used today. 
• WCAG 2.1 was published in 2018 and added 17 new success criteria. It introduced a greater focus on mobile use, touch interfaces, people with impaired vision and people with cognitive disabilities. 
• WCAG 2.2 was published in 2023 and added nine new success criteria. The focus is primarily on making websites and apps easier to use with a keyboard, mouse and mobile device. This includes clearer indication of the element being navigated to with a keyboard, larger or better-spaced clickable elements, and simpler login and longer form processes. 
• WCAG 3.0 is still under development. It is intended to provide a more flexible and broader approach to digital accessibility, but it is not yet an official standard and does not replace WCAG 2.x. 

For a complete overview of WCAG requirements, W3C has compiled all success criteria from WCAG 2.0, 2.1 and 2.2. The overview follows the four POUR principles and makes it possible to view the requirements by levels A, AA and AAA See the complete WCAG overview from W3C.

Accessibility Statements in a Public-Sector Context

An accessibility statement is a legal requirement for public websites and mobile apps covered by the Danish Web Accessibility Act. 

The statement must provide users with an accurate picture of the solution’s accessibility. Among other things, it must describe known issues, make it possible to request accessible content and explain how users can contact the organisation if they encounter barriers. 

The accessibility statement must be easy to find, easy to understand and kept up to date. It must be updated when changes to the solution affect the information in the statement, and at least once a year. 

An accessibility statement is not the same as a general accessibility statement on a private website. It also does not replace the work required to improve actual accessibility. The statement must reflect reality and make it easier for users to get help when something does not work. 

We Can Help You with WCAG 

Do you need help making your website, online store or app more accessible? At itpilot, we can help translate WCAG principles into practical improvements to design, content and functionality – both when an existing solution needs to be optimised and when accessibility needs to be considered from the outset of a new project.

Contact us for a no-obligation conversation about how we can help you move forward. Call us on +45 87 25 07 87 or complete the contact form.