What is WCAG?
WCAG stands for Web Content Accessibility Guidelines and is a set of international guidelines published by the World Wide Web Consortium (W3C). The purpose is to make web content accessible to everyone — regardless of whether users have visual, auditory, motor, or cognitive disabilities.
The guidelines are structured as a hierarchy of principles, guidelines, and testable success criteria. WCAG 2.1, published in June 2018, added 17 new success criteria to the previous version WCAG 2.0, with a particular focus on mobile users and users with cognitive disabilities. A newer version, WCAG 2.2, was published in 2023 and adds a further nine criteria.
The Four POUR Principles
All of WCAG is built around four overarching principles, collected in the acronym POUR. These principles form the foundation for all success criteria and serve as a checklist for what accessible web content requires:
- Perceivable: Content and user interface must be presented in ways users can perceive — e.g. alternative text for images, captions for video, and sufficient colour contrast.
- Operable: The interface and navigation must be operable by everyone — including full keyboard navigation for users who cannot use a mouse, and sufficient time to complete tasks.
- Understandable: Content and operation must be understandable — with clear and simple language, predictable navigation, and assistance with form errors.
- Robust: Content must be reliably interpreted by assistive technologies such as screen readers and braille displays — now and in the future as technologies evolve.
The Three Compliance Levels: A, AA, and AAA
WCAG operates with three levels of compliance. Level A (minimum) covers the most basic requirements — without this, web content is effectively inaccessible to many users. Level AA is the broad standard referenced in legislation in Denmark and across the EU. Level AAA is the most demanding and is not always achievable for all content, but represents best practice.
Level AA requires, for example, that normal text has a contrast ratio of at least 4.5:1 against the background, that large text (18pt+) has at least 3:1, that text can be scaled to 200% without loss of content or functionality, and that all form fields have programmatically associated labels.
Who Must Comply with WCAG 2.1?
In Denmark and across the EU, all public authorities are legally required to comply with WCAG 2.1 AA for their websites and mobile applications. The requirement stems from the EU Web Accessibility Directive (Directive 2016/2102), implemented in Danish law via the Act on Accessibility of Public Sector Bodies’ Websites and Mobile Applications.
The directive applies to state bodies, regions, municipalities, and a wide range of public law entities. Intranets and extranets used exclusively by employees are exempt — but public bodies with publicly oriented digital solutions are generally covered.
Private businesses are not generally required to comply with WCAG, but the European Accessibility Act (Directive 2019/882) will from June 2025 impose accessibility requirements on certain private companies for selected products and services — including e-commerce platforms, banking services, and electronic communications services.
Accessibility for PDF Documents
A frequent challenge for public authorities is PDF documents. PDFs are technically not web content and fall outside WCAG’s direct scope — but guidance suggests that if a PDF is the only access to information, it must either meet the PDF/UA standard or be supplemented with an accessible HTML alternative.
PDFAccess offers a practical solution here: the tool converts PDF documents to WCAG 2.1 AA-compatible HTML directly in the browser, without any data leaving the user’s device. This gives public institutions and libraries a quick and free method to make existing PDF documents accessible to all.
Getting Started with WCAG
A good approach to WCAG compliance is to start with an automated test of your website using free tools such as WAVE (Web Accessibility Evaluation Tool) or axe DevTools. These can identify obvious errors such as missing alt text, low contrast, and incorrect use of heading levels.
Automated tests cannot catch all issues, however — particularly questions of understandability and operability require manual review and ideally user testing with people who use assistive technologies. A combination of automated and manual tests gives the best results.