Interpretation and overview of test procedures for WCAG 2.0 A and AA

This article documents the Authority's interpretation of WCAG 2.0 with a brief overview of the associated test procedures, the method for selection of web solutions and test pages, and a data model for analysis.

Published: 09. Jan 2019, Last modified: 29. Mar 2019

1. Introduction and background

The Agency for Public Management and eGovernment (Difi) supervises public and private companies’, associations’ and organisations’ compliance with the Norwegian regulations on universal design of ICT (in Norwegian).

As a public authority, we have a strong commitment to transparency and documented methods. The Authority’s methods to measure the degree to which individual ICT solutions are in compliance with the regulations, are based on a documented interpretation of the regulations and have been designed to ensure that the Authority’s test results can be checked and verified. The methods for measuring universal design are used for both audits and large scale monitoring.

In the following, we explain the Authority's work on

  • interpretation and operationalisation of the minimum requirements for web solutions that follow from the Regulation on universal design of information and communication technology (ICT) solutions (Web Content Accessibility Guidelines (WCAG) 2.0 levels A and AA, with some exceptions)
  • methods for sampling and testing/verification of web solutions and criteria for assessing compliance with the regulations

2. Indicators and test procedures for universal design of web solutions

2.1 Prerequisites

It is not possible to tell directly from an ICT solution whether it is universally designed. We therefore use indicators that indicate or specify the degree of compliance with the requirements. When measuring universal design of ICT solutions, we also want to investigate whether there is a particular type of solution, type of content or function that stands out in terms of compliance or non-compliance with the regulations. In addition, we can also assess the results of universal design of ICT within different sectors of society and industries. Further, we want to know what consequences a lack of universal design can have for users with different user prerequisites. These perspectives shall be safeguarded by the Authority’s indicators for universal design.

The prerequisites for the work are:

  • Validity: Methods must have a high degree of validity and build directly on a documented interpretation of each individual success criterion.
  • Reliability: Methods must be designed in such a manner that they generate reliable test data. Regardless of who performs the tests, the tests must as far as possible yield the same result.

A high degree of validity and reliability is therefore the core of the Authority’s work on indicators. By documenting the work, we will facilitate transparency and make the method easy to use for any authority, supplier of web solutions or organisation that is defining specifications for or assessing its own ICT solution.

The indicators shall meet the following needs:

  • The requirements are interpreted and described in such a way that they are measurable.
  • By using the test procedures, we generate test results for each individual requirement.
  • By collating information and results from several tests, we get an overview of the exctent to which a web solution is designed in accordance with the regulations.
  • The measurement result for individual solutions, can be expressed as qualitative information about the solutions and as statistics that provide information about all the ICT solutions tested.
  • Statistics generated from tests are also analysed together with metadata about the ICT solutions and the organisations that use the solutions in their contact with customers and the public.

The tests must, as far as possible, provide the same information, regardless of who performs the test. It must be apparent what types of content, functionality and other properties are to be assessed by each individual indicator. It must also be apparent what is required to comply with each individual requirement.

2.2 The indicators and test procedures

The indicators are largely based on manual testing by experts on a sample of web pages in a website. We aim to automate as much as possible of the testing, with the prerequisite that automated testing is based on a documented and established interpretation of WCAG 2.0, and additionally generates qualitative and quantitative test data suitable for both supervision and analysis.

The work is interdisciplinary:

  • The international standard WCAG 2.0 is part of the Norwegian regulatory framework, and interpretation of success criteria requires legal expertise.
  • We need technological expertise to understand the technical content of the success criteria and prepare test procedures.
  • We need methodological and analytical expertise to ensure that the measurement methods reflect the Authority’s interpretation of the success criteria and are documented in a manner that ensures that our tests and measurements generate reliable and relevant data, both qualitative and quantitative.

2.3 Elements included in the Authority’s indicators and test procedures

The Authority has built on the World Wide Web Consortium (W3C)’s document on testing of web solutions against the success criteria in WCAG 2.0:

In light of the Authority’s needs, linked to both enforcement of the regulations and the processing of data for statistics and analysis, we have also included other elements in the methods than those described in these documents. This applies primarily to quantification of test results and connection to metadata for further analysis.

The elements in the method are listed below.

Interpretation of WCAG 2.0
  • What is the purpose of the success criteria?
  • What content or functionality do the success criteria apply to?
  • Which use situations are the success criteria intended to take into account?
  • What must be met for the test to indicate compliance (or non-compliance) with the success criteria?
Test procedures
  • Step-by-step description of the test procedure.
  • Standardised template for registering test data.
  • Automatic generation of pre-defined (descriptive, text-based) test results, based on registered test data.
Scale for test results
  • A scale for an overview of how many test objects that comply or not comply with the success criteria.
  • A scale for an overview of how many success criteria have been complied or noncomplied with.
Data model
  • Quantitative test results, graded scale and percentage, suitable for detailed overviews, aggregated statistics and analysis.
  • Metadata, about ICT solutions and organisations that are responsible for the solutions.
  • Export of data for audit reports, statistics and analysis.

There follows an explanation of the different steps and the elements of the method.

2.3.1 Interpretation of the success criteria in WCAG 2.0

The success criteria operationalised in the test procedures, are varied and complex. They cover everything from detailed technical coding and structural requirements, to more judgement-based requirements for formulation of links, error messages, labels and headings.

The Authority’s interpretation of success criteria is based on

Besides the wording of the criteria, the articles linked to each success criterion with information about how it should be understood, are also an important source. These articles explain in detail the purpose of the success criteria, list what use situations the success criteria are intended to take into account, and provide examples of solutions that are compliant or non-compliant with WCAG 2.0. In addition, we have techniques that provide more detailed information about the success criteria and tips for testing methods. Information is also provided regarding the expected result of a test, providing important input on how to define what is required to comply with the requirement.

An important part of the interpretation is to clarify what types of content, functionality and structural elements the success criterion is relevant for. This follows from the wording of the success criterion, the explanatory articles and techniques. Nevertheless, it is necessary to specify in each test procedure what type of test object it is appropriate to verify. The Authority has interpreted each individual success criterion on the basis of an overall review of the sources referred to above, together with a consideration of what it is expedient and possible to test.

2.3.2 Test procedures and categories of test results

The test procedures are described at a level that ensures that the Authority’s tests and verifications can be repeated and checked. The type of content and functionality are identified, based on an interpretation of the requirement. The test object may for instance be an isolated element (such as an image) or the entire web page. Different testers should easily be able to identify relevant content and functionality, carry out the same tests, register the same type of data through the test, and produce consistent and reliable test results.

Step-by-step methods of testing will make the actual testing process more efficient because the individual tester is guided through the entire test procedure. The steps in the procedure are also formulated with a view to minimising the amount of data that the tester has to register during the test. Therefore, the steps are largely formulated as yes/no questions. The tester receives automatically generated test data or results derived from the registrations. The test results are pre-defined, standard formulations that are derived from the combinations of the data the tester has registered in the various test steps.

The result of the tests should result in one of the following outcome categories:

  1. Compliance: The test result indicates compliance with the success criterion.
  2. Non-compliance: The test result indicates non-compliance with the success criterion.
  3. Not applicable: Several situations may result in a “not applicable” result. This may be the case if the type of content or the functionality the success criterion applies to
    • either is not actually present on the test pages (for example the pages do not contain any video clips)
    • or the type of content exists, but falls outside the requirement (for example there is a video clip, but it has not been prerecorded)
  4. Not tested: Several situations may result in a “not tested” result. This may be the case if
    • the success criterion is not included in the test. For example, we have chosen a set of test procedures that are relevant for monotoring, which covers 16 success criteria (see section 5.8 for more information). Success criteria that are not included, will generate the result “not tested”
    • the content or functionality the success criterion applies to is present on the web page, but cannot be tested. For example, success criterion 2.1.1 requires that you must be able operate the webpage though a keyboard interface. To be able to perform the test, we need a visible keyboard focus indicator. If this does not exist, it is not feasible for us to test the webpage

The different types of outcome are closely linked to the W3C document “Evaluation and Report Language (EARL)”.

When the test results are standardised and reflect several possible outcomes, we are also able to evaluate whether, for example, the same type of non-compliance occurs on many websites, or whether the instances of non-compliance are more or less evenly distributed over several types of situations. Similarly we learn whether there is large variation in the way the success criteria are met, or whether some methods stand out as more widely used than others. This is important additional information and increases the value of the tests, both for checking individual solutions and in monitoring larger volumes.

With pre-defined outcomes based on data registered in a test, we ensure that the assessment of the test result is as objective as possible, and less dependent on the individual tester’s judgement.

In the same way as the design of the test steps using yes/no questions, auto-generated and standardised test results will provide a more efficient testing and better quality in the results. This makes it possible to define a scale that reflects the test results, which can be used to generate quantitative data and statistics.

2.3.3 Scale for assessment of test results

The test results we referred to in the previous section, are formulated as text. We use a simple method to quantify the test results with the goal of establishing a basis for benchmarking and analysis. The purpose is to quantify the degree to which websites are designed in compliance or non-compliance with the regulations. The scale is used for monitoring volumes of websites, but not for checks in audits.

The scale calculates the score per test. Scores per test can be added up to give a score per success criterion, and furthermore, added up to give a total score for the website. The results can also be aggregated for all the websites in a monitoring and represent a total score or indicator for universal design.

Using metadata about the web solutions, we can also evaluate which area or topic, seen as a whole, is most in compliance or non-compliance with the regulations, such as navigation, forms, media content, etc.

We measure the results by using

  • a scale for an overview of how many success criteria have been complied or noncomplied with. By giving 1 point per success criterion where all test objects are in compliance, the scale shows how many success criteria that are fully complied with on a website.
  • a scale for an overview of how many test objects that comply or not comply with the success criteria. The scale shows the number tests that show compliance with the success criteria, in percentage of the total amount of tests being conducted. Thus, we measure the extent to which a web solution is in compliance with the regulations

An example is shown in the table below.

Test (success criterion)

Number of test objectsNumber of compliant test objectsNumber of non-compliant test objectsPoints (number of success criteria fully complied with)Percentage score (percentage of tests that show compliance)
1.1.1a15 images5 images10 images0 points33%
1.3.1a20 headings20 headings0 headings1 point100%
3.3.2a18 labels16 labels2 labels0 points89%

Maximum achievable results (in points or percentage) is corrected for the occurrence of the types “not applicable” and “not tested”.

The goal is to generate data for analysis, both per website and in more aggregated analyses.

2.3.4 Data model for analysis

Quantitive test data provides information regarding the degree to which web solutions are designed in compliance with WCAG 2.0. By linking test data to metadata about the web solutions and organisations included in a measurement, we significantly increase the information value. Test data is collated with information about what sector of society the organisations responsible for the solutions belong to. In this way we uncover which areas of society have the highest risk for digital barriers. Based on the understanding WCAG articles, we have also defined metadata on use situations and user groups for each success criterion. The success criteria are mainly intended to take into account people with

  • limited vision or without vision
  • limited perception of colour
  • deaf-blindness
  • limited hearing or without hearing
  • cognitive limitation
  • limited manipulation or strength
  • seizure disorders

The metadata also reflects that several success criteria make web solutions more usable for all users.

Test procedures an test data is also collated to metadata that shows what content type, structural elements or functionality the test applies to. This is illustrated in the table below.

CategoryExample of type of content or functionality
Alternative format
  • Text alternative for images and other non-text content
  • Video captions
Use of forms
  • Instructions and labels
  • Error messages
  • Possibility to modify or undo submission of forms that cause commitments, transactions or delete user data. which provides obligations for the user
  • Change of context
Content markup
  • Headings
  • Tables
  • Lists
  • Form elements and buttons
  • Iframe
  • Language of page and other parts of the content
  • Code syntax
Navigation
  • Meaningful sequence
  • Visual identification of links, purpose of links
  • Use of colour
  • Audio control
  • Contrast between text and its background
  • Resizing of text
  • Images of text
  • Time limits
  • Pause/stop/hide
  • Content that flashes
  • Descriptive page titles and headings
  • Multiple navigation mechanisms
  • Consistent navigation and identification
Keyboard operation
  • Functionality is operable
  • Keyboard trap
  • Shortcut skip link
  • Keyboard focus order
  • Visual focus indicator
  • Change of context on focus

Other examples of metadata are categories of test methods, such as manual, automated or semi-automated, and the purpose of the test (audits/supervision or status monitoring).

We have established a data model to structure the Authority’s data set. The data model is flexible, meaning we can always add new metadata and link it to, for example, existing test results.

The data model shall serve several purposes:

  • Using the metadata on content types and functionality, we can identify what test procedures we need to verify, for example, forms. Similarly, we will use the same data model to analyse the test data, and evaluate the degree of compliance or non-compliance with the regulations for all the forms included in a measurement.
  • By linking the test data from the verification of the solutions to information about which sector of society the organisations responsible for the solutions belong to, we can uncover digital barriers on different areas of society.
  • Using metadata that shows the different use situations that the success criteria are intended to take into account, we get information regarding the consequences of lack of universal design.

The Authority analyses the test results in combination with metadata and other data sources, in order to uncover areas of risk that need follow-up in audits.Metadata is thus an important part of the data model. We can target measures to a much larger degree by linking these data sources with test data. This applies both to targeting the control activities towards risk areas and in assessments of consequences of non-compliance for different user groups.

3. Selection of web solutions and test pages for monitoring

The Authority conducts large scale monitoring based on a sample of web solutions. The purpose of sampling is to uncover digital barriers on different areas of society. We also emphazise that the selection of pages within a website include important content types and functionalities.

The Authority analyses the test results in combination with metadata and other data sources, in order to uncover areas of risk that need follow-up in audits.

Our starting point is the recommendations regarding testing solutions against WCAG 2.0. The sampling method are adapted to safeguard the Authority’s need for information about websites and data at a more aggregated level.

3.1 Selection of web solutions

Risk and materiality are the main principle in the selection of websites. The purpose is to focus on areas where

  • there is a high risk of non-compliance with the regulations
  • non-compliance with the regulations has consequences for many users

We use different sources of information for identification of which sectors and industries in particular ought to be weighted in the selection. We focus on services that have websites with a large volume of users, primarily in industries with a certain degree of risk.

In Norway, as in a number of other countries, we do not have a complete register of public and private websites to draw a sample from. Surveys carried out by the Authority show that more than 90 per cent of Norwegian companies (with more than three employees) have websites. In a sample survey of companies with more than 50 employees, all the companies had websites. We have therefore come to the conclusion that we can use the public register of companies as a basis for identifying companies and web solutions for monitoring and area surveillance.

Due to the fact that risk and materiality are the guiding principles for selection of websites for monitoring, the sample will not necessarily be representative of all the websites in Norway. In a representative sample of Norwegian companies, the majority would be relatively small. In order to ensure the sample covers organisations with websites that are assumed to have large user volumes, we use the number of employees, the number of residents (for municipal websites) and general market knowledge as criteria for selection.

When selecting a sample for monitoring, we also collect other data. Through questionnaires we record, among other things, when the solutions were acquired. This forms the basis for identification of websites acquired after the deadline for compliance with the regulations on universal design came into force. In these surveys we also ask if the organisations have (or have plans to develop) mobile applications. We use this information to put together a sample of mobile applications for, at a later stage, monitor the status of universal design for apps.

3.2 Selection of test pages

For the purpose of monitoring, we select a sample of up to ten test pages per website. This is in order to create a consistent basis for comparison, and to ensure that we weight content types and functionality equally in all websites.

In audits, the sample is built on the topic for the audit and documentation about the most used pages on the website. Further, the sample must reflect the page types and templates used on the website and the most commonly used user tasks. Method for selecting web pages, is based on the W3C document WCAG-EM 1.0.

We put together a sample based on the following criteria:

  1. The sample shall cover the main pages used to convey the purpose and content of the websites, for example:
    • Front page, home page or other page with information about the organisation.
    • The main content on the pages.
    • Other important information.
  2. The sample shall include pages that contain:
    • The most important user tasks in the web solution, with content and functionality that is decisive for self-service, such as forms.
    • All pages included in a selected process, as far as possible without actually completing any financial transactions.
  3. The sample must also cover other important pages on the website, with content that is relevant for the topic or success criteria included in the monitoring. Thus, a sample will in most cases include pages containing images or illustrations, tables and media content etc.
  4. Other topics that are less dependent on a specific page selection, such as links, headings, body text, keyboard navigation, possibilities for enlargement, etc., will generally be evaluated in pages selected on the basis of the criteria listed in points 1-3. Should this not be the case, the sample of pages will be supplemented with pages making it possible to verify all the types of content and functionality that are relevant for the measurement.

In addition to the selection of test pages, we also specify routines for performing large scale monitoring, which include how many test objects, for example, the number of images, links, etc. that must be verified for each success criterion. The selection of websites and web pages for testing, will be described in each monitoring report.

4. Web Content Accessibility Guidelines (WCAG)

The version of the standard that has been incorporated into the Norwegian regulations for the design of web solutions, WCAG 2.0, has a hierarchical structure with four principles and 12 guidelines linked to the overarching principles.

The four principles of WCAG 2.0 are:

  1. Perceivable: Information and user interface components must be presentable to users in ways they can perceive.
  2. Operable: User interface components and navigation must be operable.
  3. Understandable: Information and the operation of user interfaces must be understandable.
  4. Robust: Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.

Each of the guidelines encompasses several success criteria formulated as technologyindependent statements. The success criteria are designed in such a manner that they can be verified. The 61 success criteria or individual requirements are classified into three levels: A, AA and AAA. It follows from the Regulation on universal design of ICT that web solutions in the private and public sector, targeting the Norwegian general public, should be designed in accordance with the success criteria (individual requirements) at levels A and AA, with some exceptions. Currently a total of 35 of the 61 success criteria in WCAG 2.0 are mandatory pursuant to the Regulation. Each of these success criteria must be regarded as mandatory requirements pursuant to the regulations that apply to web solutions.

WCAG 2.0 also refers to a range of recommendations and techniques for how to make the content of web pages more accessible. If we adhere to these recommendations, we can make the content available to individuals with disabilities, such as people with cognitive limitations, limited motor skills, hearing loss, deafness, blindness and low vision. It is also a significant point that adhering to the guidelines in WCAG, will improve the usability for all users.

This report documents the Authority’s interpretation of the success criteria or requirements in WCAG 2.0 with associated methods for testing and verification. The choice of test objects (pages), test procedures and criteria for compliance and non-compliance, is based on this interpretation. Furthermore, this is the basis for generating qualitative and quantitative test results, which are at the core of the Authority’s indicators for universal design.

5. Interpretation of WCAG 2.0 and associated test procedures

In the following, we present the Authority's interpretation of the 35 criteria for success in WGAC 2.0 that are mandatory according to the Norwegian regulations. The overview of test procedures to measure compliance or non-compliance is directly derived from the interpretation. The actual test procedures that describe in detail how the tests are to be carried out, are documented in Excel spreadsheets.

Success criterion 1.1.1 Non-text content

Purpose of 1.1.1

Non-text information must be accessible as text so that we can perceive it using different senses, such as sight, hearing and touch. We can thus convey information in a way that is adapted to users’ needs. For example, a person who is unable to see an image may have a text alternative read out that describes the content of the image. Correspondingly, someone who is unable to hear can read a text alternative. It must also be possible to make text alternatives accessible via screen readers or other assistive technology. Moreover, anyone who has difficulties understanding images and illustrations for a variety of other reasons can get help to interpret information using text alternatives that they can read or have read out to them.

Use situations for 1.1.1

This success criterion is primarily intended to take into account individuals who have or may have difficulties perceiving visual content. This includes people with

  • limited vision or without vision
  • limited hearing or without hearing
  • deaf-blindness
  • cognitive limitation

Having text alternatives for content in complex illustrations is user-friendly for everyone.

Interpretation and specification of 1.1.1

This requirement means that there must be text alternatives for non-text content with the same purpose as the non-text content. The wording of the success criterion includes a list of a number of content types and situations where the requirement involves more detailed specification of the text alternative for each individual situation, e.g. CAPTCHA.

In our operationalisation of the requirement, we have assumed that the following types of non-text content are relevant for verification:

  • Non-linked image that is
    • purely decorative
    • a specific sensory experience or a test
    • meaningful
    • complex, such as organisation charts or graphs
  • Linked images, i.e. links containing images.
  • Image maps with one or more clickable areas.
  • CAPTCHA in the form of an image, sound or logical task.

The purpose of this is to avoid testing the same linked image or image map several times.

Form instructions that are images are relevant to success criteria 1.1.1 and 3.3.2. The test procedure for verification of these kinds of images is linked to success criterion 3.3.2, so form instructions of this type are tested more comprehensively.

Test procedures, content types and requirements for compliance with 1.1.1

Test procedures for success criterion 1.1.1:

  • 1.1.1a Image has a text alternative.
  • 1.1.1b The purpose of a linked image is explained by a link text and/or text alternative.
  • 1.1.1c The purpose of selectable regions in image maps is explained by a text alternative.
  • 1.1.1d CAPTCHA has a text alternative and an alternative form.

In the table below, we explain what content has been tested and what is defined as a criterion for the solution to be in accordance with the success criterion.

No.Test procedureTest objectHow to achieve compliance with the requirement
1.1.1aImage has a text alternative
  • Non-linked image that is purely decorative, sensory experiences, meaningful or complex
  • Images that are purely decorative are coded in such a way that they do not cause confusion
  • Images that are a sensory experience or test have a short text alternative that provides a descriptive identification
  • Images that are meaningful have a short text alternative that provides the same information as the image
  • Images that are complex have both a short and a supplementary text alternative that provides the same information as the image
1.1.1bThe purpose of a linked image is explained by a link text and/or text alternative
  • Linked image
The requirement can be met in several different ways.
  • For linked images, information on the link target is provided by one of the following alternatives:
    • The link text.
    • The text alternative for the image.
    • The link text and the text alternative for the image together.
1.1.1cThe purpose of selectable regions in image maps is explained by a text alternative
  • Image map with clickable areas
  • For clickable areas in image maps, information on the link target is provided by the text alternative
1.1.1dCAPTCHA has a text alternative and an alternative form
  • CAPTCHA in the form of an image, sound or logical task
  • If CAPTCHAs with non-text content are used, the following requirements are met:
    • There are at least two types of CAPTCHA, e.g. in the form of an image, sound or text.
    • Non-text content has a text alternative that identifies and describes the purpose.

Success criterion 1.2.1 Audio-only and video-only (Prerecorded)

Purpose of 1.2.1

Information that is conveyed via prerecorded audio-onlyor video-only must be accessible to all users. Alternatives to audio and video must be designed so that the information can be accessed via different sensory modalities (by sight, hearing, touch) adapted to the needs of various users. Alternatives must be designed so that they can also be accessed using assistive technology.

For example, a person with low hearing can access information conveyed in a video by means of text or transcription of sound. A person with low vision can access information in the form of sound or in a tactile format.

Use situations for 1.2.1

This requirement is formulated to take into account people who have difficulties perceiving visual content and/or audio content. This includes people with

  • limited vision or without vision
  • limited hearing or without hearing
  • deaf-blindness

Interpretation and specification of 1.2.1

Exceptions to the requirements for alternatives for audio-only and video-only are described in success criterion 1.2.1 and the understanding article for 1.2.1. The following are excepted from the requirement:

  • Audio and video that are intended as a media alternative to text and are clearly marked as such (cf. success criterion 1.2.1). For a media alternative to be clearly marked, the following requirements must be met:
    • It is displayed in the direct vicinity of the text and there must be no doubt that it is a media alternative for the text in question.
    • It comes before information that shows it is a media alternative, e.g. an icon indicating that it is a media player, or a link that says “listen to the text”, for example, and is linked to an adjacent text.
  • Audio track that is an alternative to video without audio (cf. the understanding article to 1.2.1).

This requirement relates to all audio-only video-only content, unless these are media alternatives to text and clearly marked as such. There is no requirement for the audio and/or video to be meaningful.

The success criterion requires that an alternative for audio-only and video-only is provided. This means that the alternative in question must be visually positioned close to the component it is to replace, and it must not be necessary to scroll to access the alternative.

In Norway, this regulation does not apply to audio tracks and video tracks without audio, which come under the Broadcasting Act; cf. the regulations, section 2(4).

Test procedures, content types and requirements for compliance with 1.2.1

Test procedures for success criterion 1.2.1:

  • 1.2.1a Prerecorded audio-only content has a text alternative.
  • 1.2.1b Prerecorded video-only has a text alternative or audio alternative.

In the table below, we explain what content has been tested and what is defined as a criterion for the solution to be in accordance with the success criterion.

No.Test procedureTest objectHow to achieve compliance with the requirement
1.2.1aPrerecorded audio-only content has a text alternative
  • Prerecorded audio
The requirement can be met in several different ways.
  • Prerecorded audio that is not a media alternative to text or video has an alternative in the form of text
  • The text alternative
    • is visually positioned near to the audio clip, or
    • can be accessed via a mechanism (link, button or similar) close to the audio clip
  • In both cases, the text alternative must
    • be coded as text and
    • convey the same primary content as the audio clip, in the same order
  • Precise reproduction of the content is not required, but all essential content must be included in the correct order
1.2.1bPrerecorded video-only has a text alternative or audio alternative
  • Prerecorded video without audio
The requirement can be met in several different ways.
  • Prerecorded video without audio, which is not a media alternative to text or audio, has an alternative in the form of text or audio
  • The alternative in the form of text or audio
    • is visually positioned near to the video clip, or
    • can be accessed via a mechanism (link, button or similar) close to the video clip
    • conveys the same primary content as the video clip, in the same order
  • Alternatives in the form of sound must also
    • be possible to play back
  • Alternatives in the form of text must also
    • be coded as text
  • Precise reproduction of the content is not required, but all essential content must be included in the correct order

Success criterion 1.2.2 Captions (prerecorded)

Purpose of 1.2.2

People who are deaf or have limited hearing must be able to access synchronised media presentations. Information given in audio tracks in videos must be accessible via text.

Use situations for 1.2.2

This requirement is formulated to take into account people who have difficulties perceiving sound. This includes people with

  • limited hearing or without hearing

Captioning synchronised media presentations may also enhance usability for many users without disabilities, e.g. in very noisy places.

Interpretation and specification of 1.2.2

Exceptions to requirements for alternatives for captions are explained in the text for success criterion 1.2.2 and the understanding article for 1.2.2. The following are excepted from the requirement:

  • Prerecorded video with captions that is intended as a media alternative to text and is clearly marked as such (cf. the wording of the success criterion.
  • For a media alternative to be clearly marked, the following requirements must be met:
    • It is displayed in the direct vicinity of the text and there must be no doubt that it is a media alternative for the text in question.
    • It comes before information that shows it is a media alternative, e.g. an icon indicating that it is a media player, or a link that says “listen to the text”, for example, and is linked to an adjacent text.

The audio content in synchronised media presentations has to be captioned. This applies to sound effects that add meaning to the content, are important in order to understand the content or convey an atmosphere.

The success criterion requires “access to be provided” to captions. Given the definition of captions in WCAG, this also includes a text alternative to speech and other sound-based information that is necessary in order to understand the media content. The text alternative must be positioned visually close to the video. This also means that it must not be necessary to scroll to view the alternative.

Test procedures, content types and requirements for compliance with 1.2.2

Test procedure for success criterion 1.2.2:

  • 1.2.2a Prerecorded video with sound has captions.

In the table below, we explain what content has been tested and what is defined as a criterion for the solution to be in accordance with the success criterion.

No.Test procedureTest objectHow to achieve compliance with the requirement
1.2.2aPrerecorded video with sound has captions
  • Prerecorded video with audio
The requirement can be met in several different ways.
  • Prerecorded video with audio that is not a media alternative to text or video has an alternative in the form of captions or a text alternative
  • Captions that either are permanent (open captions) or can be enabled (closed captions) must
    • convey the content of audio and video
    • contain the following components: speech and dialogue, indicating who is speaking, and audio content that is important in order to understand the video
    • be visible but not disrupt important content in the video
  • Text alternative, alternatively the video can have a text alternative that is visually positioned close to the video clip or can be accessed via a mechanism (link, button or similar)
  • The text alternative must
    • be coded as text
    • convey the content of audio and image, and contain the following components: speech and dialogue indicating who is speaking, and audio content that is important in order to understand the video
  • Precise reproduction of the content is not required, but all essential content must be included in the correct order

Success criterion 1.3.1 Info and relationships

Purpose of 1.3.1

Information or relationships that can be perceived by people who can see and/or hear must also be accessible to other users. To make information content in various content types accessible to all, the content types (such as headings and tables) must be coded in accordance with the visual presentation.

Sighted users can perceive structures and relationships by means of visual hints, such as

  • headings, that may be in larger type or bold type, separated from the section below by a line break
  • list points that start with a bullet or similar shape
  • tables to organise data into rows and columns with headers in order to show different types of data
  • groups of form elements that share the same labels.
  • words that have different statuses (e.g. links and quotations) and are indicated with different font types, underlining, bold type or italics
  • audio signals can also be used to show structure: for example, a sound can mark the start of a new section or part of the content

Coding content types correctly will make them accessible to users who cannot see and/or hear as well.

Use situations for 1.3.1

This success criterion is intended to take into account users with various disabilities by ensuring that user agents and assistive technology can present content adapted to meet the needs of various users. This includes

  • people without vision
  • people with deaf-blindness

Interpretation and specification of 1.3.1

The wording of the success criterion paves the way for communication of information, structures and relationships either to be determined programmatically or appear as text.

In some cases, it will not be technically possible to display information or relationships in other formats. In such instances, information, structures and relationships must be explained in the form of text. The understanding article for this success criterion nevertheless emphasises that if it is technically possible to determine the info and relationships programmatically, this is recommended rather than making the information available as text. The Authority’s operationalisation of this success criterion is limited to verifying whether information, structures and relationships have been determined programmatically.

This success criterion applies to all content types, structural components and relationships. In the operationalisation of the requirement, the Authority has chosen to incorporate the following content in the test procedures: Headings, lists and bullet points, tables, form elements and groups of form elements. To avoid testing a single element several times due to the fact that there are requirements that apply to the same content in multiple success criteria, test procedures for coding form elements and groups of form elements are linked to success criterion 4.1.2. This success criterion requires both the name and the role of the content component to be determined programmatically. Therefore, it is most appropriate to test coding of form elements in connection with success criterion 4.1.2.

Content types, structural components and relationships that are currently not covered in the test procedures are paragraphs, quotations and references, superscript and subscript, tables used for layout, and WAI-ARIA regions and landmarks.

Test procedures, content types and requirements for compliance with 1.3.1

Test procedures for success criterion 1.3.1:

  • 1.3.1a Headings are coded correctly.
  • 1.3.1b Tables and header cells are coded correctly.
  • 1.3.1c Lists are coded correctly.

In the table below, we explain what content has been tested and what is defined as a criterion for the solution to be in accordance with the success criterion.

No.Test procedureTest objectHow to achieve compliance with the requirement
1.3.1aHeadings are coded correctly
  • Visual headings
  • Hierarchy of visual headings
  • Visual headings are coded as headings
  • Headings that are included in a visual heading hierarchy are coded with the correct heading level
1.3.1bTables and header cells are coded correctly
  • Tables (information structured in rows and columns)
  • The following content in tables is coded semantically correctly:
    • Table caption.
    • Header cells in tables with headings in just one row or column.
    • Header cells in tables with headings in both a column and a row.
    • Header cells in tables with headings on several rows and/or columns inside the table.
1.3.1cLists are coded correctly
  • Visual lists (grouped information, marked with bullet points or numbers, for example)
  • Visual lists are coded as follows:
    • Ordered lists are coded as ordered lists.
    • Unordered lists are coded as unordered lists.
    • Description lists (lists that have two levels and provide supplementary explanations) are coded as description lists.

Success criterion 1.3.2 Meaningful sequence

Purpose of 1.3.2

Screen readers and other assistive technology must be able to present content in the same meaningful sequence as the visual presentation on a website. Content that is not presented in a logical reading order may confuse the user and render the content inaccessible.

Use situations for 1.3.2

This success criterion is intended to take into account users who rely on having content on a website read out using assistive technology. This includes people with

  • limited vision or without vision
  • deaf-blindness

Interpretation and specification of 1.3.2

The same meaningful sequence in which the content is presented on a page must be observed when presented by a screen reader. The understanding article for the success criterion indicates that a sequence is meaningful if the order of the content in the sequence cannot be changed without affecting its meaning. The semantics of some elements define whether or not their content is a meaningful sequence.

Examples of meaningful sequences include

  • content coded as text
  • content coded as a table
  • content coded as a ordered list

Unordered lists are not deemed to be a meaningful sequence.

The understanding article otherwise specifies the following:

  • Providing a particular linear order is only required where it affects meaning.
  • There may be more than one order that meets the requirement to present content in a meaningful order.
  • Only one correct order needs to be provided.

Test procedures, content types and requirements for compliance with 1.3.2

Test procedure for success criterion 1.3.2:

  • 1.3.2a Meaningful reading order is programmatically determined.

In the table below, we explain what content has been tested and what is defined as a criterion for the solution to be in accordance with the success criterion.

No.Test procedureTest objectHow to achieve compliance with the requirement
1.3.2aMeaningful reading order is programmatically determined
  • Content that is presented in a meaningful order
  • The requirement can be met in several different ways
  • The reading order of content in a display with CSS disabled, compared with standard display, is either
    • the same
    • a reading order that otherwise presents the same meaning of the content

Success criterion 1.3.3 Sensory characteristics

Purpose of 1.3.3

The purpose of this success criterion is to ensure that all users can perceive instructions for using content, even if they are unable to perceive shape or size or use information on spatial positioning or orientation. Some assistive technologies do not perceive the shape or position of content components, e.g. “round” or “on the left”. This success criterion requires that more information be given in order to clarify this type of information.

Providing information by means of shape, position or similar is nevertheless an effective method for many users, including individuals with cognitive limitations. It is therefore possible to refer to sensory characteristics such as “the round button”, but more information must also be provided.

Use situations for 1.3.3

This requirement is formulated to take into account people who are blind or have low vision and therefore have problems with perceiving information on sensory characteristics. This includes people with

  • limited vision or without vision
  • deaf-blindness

Interpretation and specification of 1.3.3

The success criterion applies to instructions for using content and requirements for the provision of more information than reference to sensory characteristics. The understanding article for the success criterion indicates that the instructions may contain words that refer to the reading order if the same reading order is observed in the code.

Clarifications:

  • Colour: A note on the success criterion indicates that the use of colour is linked to success criterion 1.4.1, which specifies that colour must not be the only visual means of conveying information.
  • Image: Instructions that are images (e.g. form instructions) come under success criterion 1.1.1 and are verified under this success criterion.
  • Running text: We do not verify instances where instructions on use that refer to the components’ sensory characteristics are specified in running text. This would be highly resource intensive, with a risk of random testing and uneven test result quality.

Test procedures, content types and requirements for compliance with 1.3.3

Test procedure for success criterion 1.3.3:

  • 1.3.3a Instructions for use of forms are not solely dependent on sensory characteristics.

In the table below, we explain what content has been tested and what is defined as a criterion for the solution to be in accordance with the success criterion.

No.Test procedureTest objectHow to achieve compliance with the requirement
1.3.3aInstructions for use of forms are not solely dependent on sensory characteristics
  • Instructions in forms that include references to sensory characteristics
The requirement can be met in several different ways.
  • Instructions that include information on components’ sensory characteristics (shape, size, visual position on the page, orientation or sound) also include other information that allows the user to find and use the component
  • This requirement may also be met if any of the following are observed
    • in the instruction, words are used that are natural in the language to refer to a reading order and the same reading order is observed in the code
    • the instruction is provided in the form of a symbol, icon or graphic representation, and this is identified in the code

Success criterion 1.4.1 Use of colour

Purpose of 1.4.1

Information that is conveyed using colour or colour differences must be accessible to all.

Colour must therefore not be the only visual means used to convey information, refer to an action, ask for a response or distinguish a visual component. Colour must be used in combination with other means such as text or a visual marker other than colour.

Use situations for 1.4.1

This success criterion is intended to take into account users who have difficulties perceiving information conveyed by means of colour or colour differences. This includes people with

  • limited vision or without vision
  • limited perception of colour

The success criterion will also increase usability for people without disabilities.

Interpretation and specification of 1.4.1

The Authority assumes that the success criterion applies only if colour is used as a means for conveying information, and not if colour is used for purely decorative or aesthetic purposes. Use of colours or colour coding is not advised against as long as other visual expressions are also used to convey the information.

The success criterion applies to all content types. The Authority’s operationalisation of the requirement in test procedures incorporates link text, information and graphic representations, form elements and error messages. The test procedure tests links in running text. Link testing does not cover links in menus and links that are grouped together and not visually positioned next to non-link content.

Test procedures, content types and requirements for compliance with 1.4.1

Test procedures for success criterion 1.4.1:

  • 1.4.1a Links are distinguishable from other text by means other than colour alone.
  • 1.4.1b Information in graphic representations is distinguishable by means other than colour alone.
  • 1.4.1c Form elements and error messages are marked by means other than colour alone.

In the table below, we explain what content has been tested and what is defined as a criterion for the solution to be in accordance with the success criterion.

No.Test procedureTest objectHow to achieve compliance with the requirement
1.4.1aLinks are distinguishable from other text by means other than colour alone
  • Links in running text (not in menus)
  • Linked headings
The requirement can be met in several different ways.
  • Links in running text are compliant with one of the alternatives below:
    • Links that are marked with colour are distinguished from adjacent non-link text by means other than colour alone, e.g. font type, font size, underlining, bold type, frames or icons.
    • Links that are marked with colour alone have a contrast of at least 3:1 to adjacent non-link text and have visible marking by means other than colour alone in the case of both mouseover and keyboard focus. Changing the cursor and standard focus indicator when navigating using a keyboard are not sufficient marking.
1.4.1bInformation in graphic representations is distinguishable by means other than colour alone
  • Graphic representations, e.g.: diagrams, organisational charts, graphic representations of transport systems and similar.
The requirement can be met in several different ways.
  • If colour is used as a visual instrument for conveying information or distinguishing visual components in graphic representations, one of the following requirements is also met:
    • Explanatory text or other visual instruments that provide the same information conveyed by use of colour. Example: pattern, shape (e.g. star, diamond, square, etc.) or a direct link between part of the illustration where colour is used and explanatory information.
    • There is a mechanism that activates such information.
1.4.1cForm elements and error messages aremarked by means other than colour alone
  • Use of colour in form elements, instructions and error messages
  • Form elements, instructions and error messages that use colour to
    • convey information
    • show an action
    • request a response
    • or distinguish a visual component

are marked by means other than colour alone and the marking is visual.

Success criterion 1.4.2 Audio control

Purpose of 1.4.2

Audio that starts automatically on a website must not interrupt audio or speech from a screen reader, speech synthesis or similar software that is reading out text content. Audio that starts automatically will make it difficult for the user to hear speech from a screen reader or speech synthesiser, and hence also make it difficult to navigate on a page.

Use situations for 1.4.2

This success criterion applies to individuals who use screen reader technology or may have difficulties focusing on visual content, including text, when audio is played back. This includes people with

  • limited vision or without vision

The possibility to control audio that starts automatically will also enhance usability for all users.

Interpretation and specification of 1.4.2

The success criterion requires a mechanism for audio control when audio started automatically lasts for more than three seconds. The mechanism for audio control must be readily accessible, and it must be possible to control the audio on the website. The success criterion indicates that the general volume control in the operating system must not be used to control the audio.

Technique G 170 linked to the success criterion indicates that a mechanism is visually positioned close to the start of the page when it is not necessary to scroll away from the start of the page in order to access it.

Test procedures, content types and requirements for compliance with 1.4.2

Test procedure for success criterion 1.4.2:

  • 1.4.2a Control of audio that starts automatically and does not stop within 3 seconds.

In the table below, we explain what content has been tested and what is defined as a criterion for the solution to be in accordance with the success criterion.

No.Test procedureTest objectHow to achieve compliance with the requirement
1.4.2aControl of audio that starts automatically and does not stop within 3 seconds
  • Web pages with audio that starts automatically and does not stop within three seconds
  • Audio that starts automatically and does not stop within 3 seconds has a mechanism for audio control that
    • is visually positioned near the start of the page
    • can be operated with a keyboard
    • is early in the tab order sequence (maximum 5 tab steps)
    • has a visual marker in the form of text or a symbol

Success criterion 1.4.3 Contrast

Purpose of 1.4.3

There must be sufficient contrast between the text and its background on the website. This will allow even users with moderately reduced vision to read the text. This also includes users with limited perception of colour.

A contrast ratio of 4.5:1 is set as this will compensate for 20/40 vision loss. Such vision loss is common amongst the elderly. This contrast will make text easier for all users to read, e.g. on a small screen (smartphone, tablet) or in sunlight.

Use situations for 1.4.3

The success criterion takes into account people with

  • limited vision
  • limited perception of colour

Sufficient contrast between text and the background will enhance usability for all users.

Interpretation and specification of 1.4.3

The success criterion indicates that the contrast requirement

  • only applies to text and not to graphic representations or illustrations
  • varies according to font size and layout (bold vs. non-bold)

The contrast requirement between text its background is 3:1 for text more than 24 pixels high in ordinary type or at least 19 pixels high in bold type. For all other text, the contrast requirement is 4.5:1.

We cannot verify font sizes in images of text. We have therefore set the limit for contrast for images of text measured against the background in the image to 3:1 (which is the requirement for a large font or bold type), and not 4.5:1 (which is the requirement for other text).

The contrast requirement is limited to text that conveys information. Other text is not included in the Authority’s test procedures:

  • Non-informative text that is purely decorative.
  • Text in logos and trademarks.
  • Text in images where the text is not essential to convey the meaning of the content.
  • Disabled form elements.
  • Text that is not visible to anyone.
  • Graphic components in e.g. diagrams and graphs, such as guides, columns, etc.

The contrast requirement may be met on web pages in ordinary view or in a high-contrast mode that is in accordance with the contrast requirements and has an accessible mechanism for activation. If there is a gradient background and/or text, contrast is measured at the lowest-contrast point.

Test procedures, content types and requirements for compliance with 1.4.3

Test procedures for success criterion 1.4.3:

  • 1.4.3a There is sufficient contrast between text and its background.
  • 1.4.3b There is sufficient contrast between text and its background in an image of text.
  • 1.4.3c There is sufficient contrast between text and its background (automated test).

In the table below, we explain what content has been tested and what is defined as a criterion for the solution to be in accordance with the success criterion.

No.Test procedureTest objectHow to achieve compliance with the requirement
1.4.3aThere is sufficient contrast between text and its background
  • Text in the form of headings, links and other text, labels, help texts or error messages in forms, illustrations and diagrams (that are not images)
The requirement can be met in several different ways.
  • 1. Text has contrast
    • of at least 4.5:1 to the background
    • of at least 3.0 to the background and the text size is at least 24 pixels, or 19 pixels bold
  • 2. There is a high-contrast version that meets the following requirements:
    • The mechanism for activation is positioned close to the start of the page and is visually marked with a text or icon.
    • The mechanism meets the contrast requirement in point 1 above.
    • Text in the high-contrast version meets the contrast requirement in point 1 above.
    • The textual component measured with inadequate contrast in ordinary view is identical to the component in the highcontrast version.
1.4.3bThere is sufficient contrast between textand its background in an image of text
  • Images of text
The requirement can be met in several different ways.
  • 1. Image of text has contrast of at least 3:1 to the background
  • 2. There is a high-contrast version that meets the following requirements:
    • The mechanism for activation is positioned close to the start of the page and is visually marked with a text or icon.
    • The mechanism has contrast of at least 4.5:1.
    • Text in the high-contrast version meets the contrast requirement in point 1 above.
    • The textual component measured with inadequate contrast in ordinary view is identical to the component in the highcontrast version.
1.4.3cThere is sufficient contrast between text and its background (automated test)
  • Text in the form of headings, links and other text, labels, help texts or error messages in forms, illustrations and diagrams (that are not images)
  • Text has contrast of at least 4.5:1 to the background

This is a simplified version of 1.4.3a, where contrast is tested automatically.

Success criterion 1.4.4 Resize text

Purpose of 1.4.4

It must be possible to enlarge text so that people with moderately low vision can read text without the use of assistive technology. It must be possible to double both the height and the width of text. This limit is set with regard to the extent to which it is possible to increase the text without causing problems with the graphic layout of the page.

Use situations for 1.4.4

The success criterion takes into account people with

  • limited vision

The possibility to enlarge text will enhance usability for all users.

Interpretation and specification of 1.4.4

It follows from the wording of this success criterion that the requirement does not apply to captioning of media content or images of text. The requirement applies to all other text written in natural language, including text in form elements.

Test procedures, content types and requirements for compliance with 1.4.4

Test procedure for success criterion 1.4.4:

  • 1.4.4a Text can be enlarged to at least 200 % view with no loss of content or functionality.

In the table below, we explain what content has been tested and what is defined as a criterion for the solution to be in accordance with the success criterion.

No.Test procedureTest objectHow to achieve compliance with the requirement
1.4.4aText can be enlarged to at least 200 % view with no loss of content or functionality
  • Text that is not captions in video or images of text
  • Text in form elements
  • All text can be enlarged to at least 200 % view without any loss of content or functionality

Success criterion 1.4.5 Images of text

Purpose of 1.4.5

Images of text may make it difficult to perceive the information being conveyed. One objective is therefore for images of text to be used only when it is not possible to present content in any other way. Using text instead of images of text allows users who need specific presentation of the text to adjust the text according to their needs. This may, for example, involve changing the font size, colour or line spacing, or if assistive technology is needed that makes text available as speech.

Use situations for 1.4.5

This success criterion is intended to take into account people who may have difficulties orienting themselves visually. This includes people with

  • limited vision or without vision
  • cognitive limitation

Interpretation and specification of 1.4.5

Images of text presenting text in a non-textual manner. This does not include text included in an image together with other essential visual content. Examples of this are graphs, screens and diagrams that convey more information than just text.

In some situations, images of text may be necessary in order to achieve a visual effect. According to the understanding article for the success criterion, this is when

  • it is not possible to achieve the desired visual effect by formatting text
  • the desired effect cannot be presented in the most common browsers
  • the presentation requires the use of techniques or technology not compliant with the requirements of WCAG 2.0

Images of text are in compliance with the requirement if the font type, size, colour and background can be adjusted.

Test procedures, content types and requirements for compliance with 1.4.5

Test procedure for success criterion 1.4.5:

  • 1.4.5a Image of text is not used unnecessarily.

In the table below, we explain what content has been tested and what is defined as a criterion for the solution to be in accordance with the success criterion.

No.Test procedureTest objectHow to achieve compliance with the requirement
1.4.5aImage of text is not used unnecessarily
  • Images of text
The requirement can be met in several different ways.
  • Image of text is not used unless:
    • image of text can be adapted to the user’s requirements or
    • image of text is necessary to present information

Success criterion 2.1.1 Keyboard

Purpose of 2.1.1

It must be possible to operate content on web pages using a keyboard, wherever feasible. The website must be usable by people who

  • are unable to use a mouse
  • use an alternative to a keyboard, e.g. speech input, switch control and on-screen keyboard

Most actions that are performed using a mouse, e.g. clicking, selecting, moving and enlarging, can also be performed using a keyboard. Specific timings for individual keystrokes must not be required. Nor should the user have to repeat or make many keystrokes in a short period of time or hold the key down for any length of time before the keystroke is registered. This is out of consideration for users with limited motor skills.

Use situations for 2.1.1

This success criterion is primarily intended to take into account people who are unable to use equipment that requires hand-eye coordination or who may have problems with finding or using content with a mouse. This includes people with

  • limited vision or without vision
  • limited manipulation or strength

Interpretation and specification of 2.1.1

It follows from the success criterion that this requirement does not apply to functionality that is not appropriate to operate with a keyboard. This may, for example, include freehand drawing or computer games where objects are guided through various obstacles, etc.

If there is more than one way of operating certain functionalities, such as the possibility to both select the date in a calendar and enter the date directly in a date field, it is sufficient that one of the methods can be used with a keyboard.

Test procedures, content types and requirements for compliance with 2.1.1

Test procedure for success criterion 2.1.1:

  • 2.1.1a Functionality of the content is operable through a keyboard.

In the table below, we explain what content has been tested and what is defined as a criterion for the solution to be in accordance with the success criterion.

No.Test procedureTest objectHow to achieve compliance with the requirement
2.1.1aFunctionality of the content is operable through a keyboard
  • All types of content and functionality on the website. A visual focus indicator during keyboard navigation is a prerequisite for the test
  • All content and functionality on the web page can be accessed and used with a keyboard. Content and/or functionality that it is not appropriate to use with a keyboard is excepted

Success criterion 2.1.2 No keyboard trap

Purpose of 2.1.2

The purpose of this requirement is to prevent users becoming trapped in a component on the web page when they are navigating using the keyboard.

Use situations for 2.1.2

This success criterion is primarily intended to take into account people who have to use a keyboard to navigate. This includes people with

  • limited vision or without vision
  • limited manipulation or strength

Interpretation and specification of 2.1.2 It follows from the wording of this success criterion that all content on the page must comply with the requirement.

Test procedures, content types and requirements for compliance with 2.1.2

Test procedure for success criterion 2.1.2:

  • 2.1.2a There are no keyboard traps on the web page.

In the table below, we explain what content has been tested and what is defined as a criterion for the solution to be in accordance with the success criterion.

No.Test procedureTest objectHow to achieve compliance with the requirement
2.1.2aThere are no keyboard traps on the web page
  • Components and elements on the web page that it is possible to navigate using a keyboard
  • It is possible to navigate through all content on the web page with a keyboard without becoming trapped in any component

Success criterion 2.2.1 Timing adjustable

Purpose of 2.2.1

People with disabilities must have adequate time to read content or execute actions on the website. Offering the option to disable, adjust or extend time limits will help anyone who needs more time than expected to perform a task.

Use situations for 2.2.1

This success criterion is intended to take into account people who need to be able to adjust the time they have available when using web pages. This includes people with

  • limited vision or without vision
  • limited hearing or without hearing
  • deaf-blindness
  • cognitive limitation
  • limited manipulation or strength

Adequate time to read content or execute actions also enhances usability for all users.

Interpretation and specification of 2.2.1

This success criterion explains exceptions to the requirement when the time limit

  • is a necessary component in a real-time event (e.g. an auction), and there is an alternative
  • is necessary, and extension will invalidate the action
  • lasts more than 20 hours

Test procedures, content types and requirements for compliance with 2.2.1

Test procedure for success criterion 2.2.1:

  • 2.2.1a It is possible to turn off, adjust or extend time limits.

In the table below, we explain what content has been tested and what is defined as a criterion for the solution to be in accordance with the success criterion.

No.Test procedureTest objectHow to achieve compliance with the requirement
2.2.1aIt is possible to turn off, adjust or extend time limits
  • Web pages that include time limits
The requirement can be met in several different ways.
  • For web pages that include time limits, one of the following requirements is met:
    • It is possible to disable the time limit.
    • It is possible to adjust the time limit to at least 10 times the standard duration. The mechanism for adjustment must come before the content that includes time limits.
    • It is possible to extend the time limit at least 20 seconds before it expires by executing a simple action. It must be possible to extend by at least 10 times the standard duration.

Success criterion 2.2.2 Pause, stop, hide

Purpose of 2.2.2

Moving content, such as video, animations, real-time games, automatic updates, etc., may lead to users being unable to concentrate on other content on the page.

It must therefore be possible to stop, pause or hide moving content, or to control the update frequency. Content that has been paused may either continue in real time or start from the point at which the content was paused.

Use situations for 2.2.2

This success criterion is intended to take into account people with

  • cognitive limitation

The option of controlling moving content will enhance usability for all users.

Interpretation and specification of 2.2.2

According to the understanding article for the success criterion, there must be a separate mechanism for pausing content, e.g. a pause button. It must be possible to use other content on the page when content has been paused. It is not sufficient for content only to be paused when it is in focus (with the cursor or keyboard focus). The objective of avoiding distracting the user is not met in this case.

The requirement does not apply to content that only moves for up to five seconds. This is because the content producer then has the opportunity to use movement, rolling or blinking as a way of attracting the user’s attention, while at the same time the distraction is brief enough for the user to be able to wait.

Test procedures, content types and requirements for compliance with 2.2.2

Test procedures for success criterion 2.2.2:

  • 2.2.2a It is possible to pause, stop or hide content that moves, blinks or scrolls.
  • 2.2.2b It is possible to pause, stop, hide or change the update frequency for autoupdating content.

In the table below, we explain what content has been tested and what is defined as a criterion for the solution to be in accordance with the success criterion.

No.Test procedureTest objectHow to achieve compliance with the requirement
2.2.2aIt is possible to pause, stop or hide content that moves, blinks or scrolls
  • Web pages with content that moves, blinks or scrolls (that starts automatically and does not stop within five seconds)
The requirement can be met in several different ways.
  • For web pages with content that moves, blinks or scrolls for more than 5 seconds and that is displayed together with other content and is not a necessary part of an action, one of the following requirements is met:
    • There is a mechanism for pausing, stopping or hiding the content. The mechanism is located either directly next to the content or at the start of the page.
    • There is a documented keyboard shortcut for pausing, stopping or hiding the content.
    • There is a mechanism close to the start of the page for reloading the page without this type of content.
2.2.2bIt is possible to pause, stop, hide or change the update frequency for auto-updating content
  • Web pages with autoupdating content that does not move, blink or scroll at the same time (for more than five seconds)
The requirement can be met in several different ways.
  • For web pages with auto-updating content that is displayed together with other content and is not a necessary part of an action, one of the following requirements is met:
    • There is a mechanism for pausing, stopping or hiding the content or controlling the update frequency. The mechanism is located either directly next to the content or at the start of the page.
    • There is a documented keyboard shortcut for pausing, stopping or hiding the content or controlling the update frequency.

Success criterion 2.3.1 Three flashes or below threshold

Purpose of 2.3.1

All content must be accessible to users with no risk of it triggering seizures as a result of photosensitivity. People who have epilepsy or other photosensitivity may have seizures triggered by website content that flashes at a certain frequency.

Use situations for 2.3.1

This success criterion is intended to take into account people with

  • seizure disorders

Interpretation and specification of 2.3.1

All content on the website must comply with the requirement, with the exception of blinking or flashing due to the screen or loading of images (cf. the understanding article).

In WCAG’s definitions of terms, there is a specific explanation of what constitutes flashing and red flashing, with associated threshold values:

  • Blinking is switch back and forth between two visual states in a way that is meant to draw attention.
  • Flashing is a pair of opposing changes in relative luminance that can cause seizures in some people if it is large enough and in the right frequency range.
  • Red flashing is defined as any pair of opposing transitions involving a saturated red.
  • Flashing must not occur at a frequency of more than three times per second, or cover more than 25% of any 10-degree visual field on screen.

Blinking above the threshold values must not occur at all. It is not sufficient to make the user aware that the page includes flashing.

It is difficult and time-consuming to verify web solutions against this success criterion. The test procedure also requires access to tools for measurement.

Test procedures, content types and requirements for compliance with 2.3.1

Test procedure for success criterion 2.3.1:

  • 2.3.1a The web page has no flashing content.

In the table below, we explain what content has been tested and what is defined as a criterion for the solution to be in accordance with the success criterion.

No.Test procedureTest objectHow to achieve compliance with the requirement
2.3.1aThe web page has no flashing content
  • Web pages with content that blinks (all content, including animations, video clips and images)
The requirement can be met in several different ways.
  • The web page has no content that flashes
  • If the web page has content that blinks, one of the following requirements is met:
    • 1. The content that flashes is smaller than 21,824 square pixels in size.
    • 2. There are fewer than three flashes per second.

Success criterion 2.4.1 Bypass blocks

Purpose of 2.4.1

The user must be able to navigate sequentially through the content and in this way gain more direct access to the primary content on the page.

Many websites have content that is repeated on several pages. Examples include

  • menus
  • navigation links
  • banner text and advertising frames

Being able to bypass this type of content means that people who use a keyboard to navigate on the website can access the primary content more quickly.

Use situations for 2.4.1

This success criterion is primarily intended to take into account people who are dependent on using a keyboard, screen magnifier or screen reader to navigate a website. This includes people with

  • limited vision or without vision
  • deaf-blindness
  • limited manipulation or strength
  • cognitive limitation

Interpretation and specification of 2.4.1

The understanding article for the success criterion shows that the requirement applies to web pages that belong to the same website, i.e. web pages that share a collective purpose and that are created by the same author, group or organisation. An explanation is also provided of situations that are excepted from the requirement:

  • Small, repeated sections such as individual words, phrases or simple links are not deemed to be blocks.
  • There is no requirement to offer methods or navigation options that are already available in the user agent (browser or screen reader).

If the user is able to tab through to the primary content relatively quickly (within five tab steps), no requirements are defined for skip links.

Test procedures, content types and requirements for compliance with 2.4.1

Test procedure for success criterion 2.4.1:

  • 2.4.1a There is a mechanism for skipping to the primary content on the web page.

In the table below, we explain what content has been tested and what is defined as a criterion for the solution to be in accordance with the success criterion.

No.Test procedureTest objectHow to achieve compliance with the requirement
2.4.1aThere is a mechanism for skipping to the primary content on the web page
  • Web pages with content that is repeated on multiple pages on the website.
  • For web pages with blocks of content that are repeated in multiple locations on the website and that come before the primary content, the following requirements are met:
    • There is a mechanism for skipping to the primary content.
    • This mechanism is within the first three tab steps, and before the block with content on the web page.
    • The mechanism is visible when it receives keyboard focus.
    • The mechanism has a descriptive text.
    • Visual and functional focus are transferred to the primary content when the mechanism is activated.

Success criterion 2.4.2 Page titled

Purpose of 2.4.2

When each web page has a descriptive page title, users will find it easier to orient themselves, find relevant content and navigate through the website. Users can identify where they are without reading and interpreting the content of the web page. Users can also find the relevant content more easily when the page titles appear in a search.

Use situations for 2.4.2

The success criterion takes into account people with

  • limited vision
  • cognitive limitation

This requirement takes into account all users as descriptive page titles make it easier to identify whether the content on a web page is relevant.

Interpretation and specification of 2.4.2

The page title must provide relevant information on the content of the page, even when the page title is read out of context (cf. technique G88). There is no requirement for page titles to be unique for each individual web page on the website, as long as it provides a relevant description of the content.

Note that the page title must not be confused with the main web page heading. Page titles are located in the <title> element, which is nested in the <head> element at the start of the HTML markup.

Test procedures, content types and requirements for compliance with 2.4.2

Test procedure for success criterion 2.4.2:

  • 2.4.2a The web page has a descriptive page title.

In the table below, we explain what content has been tested and what is defined as a criterion for the solution to be in accordance with the success criterion.

No.Test procedureTest objectHow to achieve compliance with the requirement
2.4.2aThe web page has a descriptive page title
  • Page title on individual web pages
  • The page title is coded correctly
  • The page title provides a relevant description of the subject or purpose of the page, even when it is read out of context

Success criterion 2.4.3 Focus order

Purpose of 2.4.3

It must be possible to understand and use the content of a web page when the user navigates through the website using a keyboard. When keyboard focus follows the visual reading order, the web page will be displayed in the same order as in the case of other navigation methods.

Use situations for 2.4.3

This success criterion is primarily intended to take into account people who are dependent on using a keyboard or screen magnifier to navigate on a website. This includes people with

  • limited vision or without vision
  • deaf-blindness
  • cognitive limitation
  • limited manipulation or strength

Interpretation and specification of 2.4.3

The understanding article for the success criterion indicates that the components on a web page must receive focus in an order that preserves both meaning and operability of the content and functionality. This applies when the focus order affects the meaning of the content and operation. Focus order in this context is the same as keyboard order.

Focus order does not have to be identical to reading order as long as the user is able to understand and use the content on the web page. Nevertheless, it is emphasised that a focus order that is very different to the reading order may confuse the user.

There may be more than one focus order that preserves the meaning and operability of the web page. It is sufficient for one focus order to comply with the requirement.

Test procedures, content types and requirements for compliance with 2.4.3

Test procedure for success criterion 2.4.3:

  • 2.4.3a Keyboard focus order preserves meaning and operability.

In the table below, we explain what content has been tested and what is defined as a criterion for the solution to be in accordance with the success criterion.

No.Test procedureTest objectHow to achieve compliance with the requirement
2.4.3aKeyboard focus order preserves meaning and operability
  • Web pages that can be navigated sequentially, and where navigation order affects the meaning of the content or operation. (Prerequisite: a visual focus indicator and keyboard operable.)
The requirement can be met in several different ways.
  • For content that receives keyboard focus and must be navigated in a specific order, one of the following requirements is met:
    • Keyboard navigation order and visual order are the same.
    • Keyboard navigation order and visual order are not the same, but it is possible to understand and use the content.

Success criterion 2.4.4 Link purpose (in context)

Purpose of 2.4.4

Links must be formulated so that the user receives information on the purpose of the link. This is intended to make it possible to assess whether it is appropriate or desirable to follow the link.

Use situations for 2.4.4

The purpose of this success criterion is to facilitate navigation and understanding of content for people with

  • limited vision or without vision
  • deaf-blindness
  • limited manipulation or strength
  • cognitive limitation

Descriptive link texts also enhance usability for all users.

Interpretation and specification of 2.4.4

The Authority assumes that there is no requirement for the link target to be described precisely in the link text, but rather that the description of the link target must not be directly incorrect.

The wording of the success criterion also indicates that the requirement does not apply if the purpose of the link would be ambiguous to users in general. In the opinion of the Authority, it is difficult to establish a good criterion to be able to make consistent assessments of whether link targets are ambiguous to users in general. Thus the verifications will involve a high level of subjective judgement. The Authority will therefore not verify this part of the requirement.

The formulation of the success criterion in the original language refers to “the link text”. The Authority therefore assumes that the success criterion only applies to links that contain text. Links that contain images are assessed under success criterion 1.1.1.

Test procedures, content types and requirements for compliance with 2.4.4

Test procedure for success criterion 2.4.4:

  • 2.4.4a The purpose of each link can be determined from the link text alone or the link text together with its context.

In the table below, we explain what content has been tested and what is defined as a criterion for the solution to be in accordance with the success criterion.

No.Test procedureTest objectHow to achieve compliance with the requirement
2.4.4aThe purpose of each link can be determined from the link text alone or the link text together with its context
  • Links that contain text
The requirement can be met in several different ways.
  • Links that contain text meet the requirement if:
    • 1. the link text alone provides information on the purpose of the link, or
    • 2. the link text together with programmatically determined context provides information on the purpose of the link
  • We provide a discretionary assessment of whether the link text provides information on the link target. We do not require the link target to be written precisely

Success criterion 2.4.5 Multiple ways

Purpose of 2.4.5

It must be possible to access web pages, content or functionality on web pages in multiple ways, suited to the needs of the individual. This may involve links, search functionality, site maps, etc.

Use situations for 2.4.5

This success criterion is primarily intended to take into account people with

  • limited vision or without vision
  • deaf-blindness
  • cognitive limitation
  • limited manipulation or strength

The requirement takes all users into account, in that multiple navigation methods will help relevant content to be found in an effective way.

Interpretation and specification of 2.4.5

The wording of this success criterion indicates that the requirement applies to web solutions comprising a set of web pages. Even smaller websites that comprise just a few pages must have multiple navigation options. Websites that comprise just one page are not covered by the requirement.

Nor does the requirement apply to web pages that are a result of or a step in a process. The various steps that have to be performed in order to buy a product in an online shop is one example of such a process. The results page produced after a search is another example.

Test procedures, content types and requirements for compliance with 2.4.5

Test procedure for success criterion 2.4.5:

  • 2.4.5a There are multiple ways to navigate.

In the table below, we explain what content has been tested and what is defined as a criterion for the solution to be in accordance with the success criterion.

No.Test procedureTest objectHow to achieve compliance with the requirement
2.4.5aThere are multiple ways to navigate
  • Navigation options for individual web pages within a set of web pages (website)
  • There must be at least two ways of navigating to content on web pages (on websites with more than one web page)

Success criterion 2.4.6 Headings and labels

Purpose of 2.4.6

When headings and labels are clear and descriptive, it is easier for users to find relevant information and understand contexts and structure in the information presented. Descriptive labels help users to identify different content components more quickly.

Use situations for 2.4.6

Descriptive headings and labels are primarily intended to take into account people with

  • limited vision or without vision
  • deaf-blindness
  • cognitive limitation
  • limited manipulation or strength

The requirement takes into account all users, in that descriptive headings and labels will help relevant content to be found in an effective way.

Interpretation and specification of 2.4.6

This success criterion does not require headings and labels. Rather, this success criterion states that if headings or labels are provided, they must be descriptive

Success criteria 2.4.6 and 3.3.2 are closely interlinked:

  • 2.4.6 relates to both headings and labels. It does not require that they be provided, but states that if they are provided, they must be descriptive.
  • 3.3.2 requires that instructions or labels are provided that identify form elements (including whether the form element is mandatory) so that users know what input data is expected.

Test procedures, content types and requirements for compliance with 2.4.6

Test procedures for success criterion 2.4.6:

  • 2.4.6a Headings describe the content.
  • 2.4.6b Form elements have descriptive labels.

In the table below, we explain what content has been tested and what is defined as a criterion for the solution to be in accordance with the success criterion.

No.Test procedureTest objectHow to achieve compliance with the requirement
2.4.6aHeadings describe the content
  • Visual headings
  • If headings are used, they must describe the subject or purpose of the content to which they belong
2.4.6bForm elements have descriptive labels
  • Labels in forms (all visible text or other components with text in the form)
  • Labels describe the subject or purpose of the form element

Success criterion 2.4.7 Focus visible

Purpose of 2.4.7

When operating content on web pages using a keyboard, there must be a visible keyboard focus indicator. This is intended to help the user to orient themselves on the page and identify content. When a page contains multiple components that can be accessed using a keyboard, the user must always be able to see which content component they have navigated to.

Use situations for 2.4.7

This success criterion helps people who have to use a keyboard to operate the web page, by indicating visually which component is in focus at any particular time. This is primarily intended to take into account people with

  • limited vision
  • cognitive limitation
  • limited manipulation or strength

Interpretation and specification of 2.4.7

The test procedure tests all types of content and functionality on web pages that can be operated through a keyboard. The requirement only applies to content and functionality that receives keyboard focus.

The understanding article for the success criterion indicates that if there is only one component on the page that can be used with a keyboard, there does not need to be a visual focus indicator. This is because there is no other content from which this component has to be differentiated.

The focus indicator should be highly visible, and the user should easily be able to see which element is in focus. Examples of a visible focus indicator include

  • a frame, line, or underlining
  • changed colour of background or text
  • shading
  • text cursor (vertical bar) or marking of text in form fields
  • other form of visual change

Test procedures, content types and requirements for compliance with 2.4.7

Test procedure for success criterion 2.4.7:

  • 2.4.7a Keyboard operable content has a visual focus indicator.

In the table below, we explain what content has been tested and what is defined as a criterion for the solution to be in accordance with the success criterion.

No.Test procedureTest objectHow to achieve compliance with the requirement
2.4.7aKeyboard operable content has a visual focus indicator
  • Keyboard operable content
  • All keyboard operable elements have a visual focus indicator. This does not apply if there is only one component that can be operated using a keyboard on a web page

Success criterion 3.1.1 Language of page

Purpose of 3.1.1

The default language of the page must be declared in the code. The purpose is to ensure that text and other linguistic content is presented correctly. Both assistive technologies and user agents can reproduce text more accurately when the language on the web page is identified. Similarly, screen readers will make text accessible with correct pronunciation, and captions in media players will be correct. This makes it easier to understand the content on web pages.

Use situations for 3.1.1

This success criterion is intended to take into account people who use different types of assistive technology (screen readers, text-to-speech technology) and functionality for captioning in order to have content presented to them. This includes people with

  • limited vision or without vision
  • cognitive limitation

Interpretation and specification of 3.1.1

The understanding article for the success criterion specifies that the default language is the language used for the majority of the content. If multiple languages are used in equal quantities, the default language is the language used first.

Test procedures, content types and requirements for compliance with 3.1.1

Test procedure for success criterion 3.1.1:

  • 3.1.1a The default language of the web page is coded correctly.

In the table below, we explain what content has been tested and what is defined as a criterion for the solution to be in accordance with the success criterion.

No.Test procedureTest objectHow to achieve compliance with the requirement
3.1.1aThe default language of the web page is coded correctly
  • Text content on web pages
  • Web page has a valid language code in the HTML code
  • The language code corresponds to the default language of the web page

Success criterion 3.1.2 Language of parts

Purpose of 3.1.2

User agents and assistive technologies must be able to present content in different languages correctly. If text in a language other than the default language of the page is identified in the code, user agents and assistive technologies can present the content in compliance with the language rules for the language in question.

Use situations for 3.1.2

This success criterion is intended to take into account people who use different types of assistive technology (screen readers, text-to-speech technology) or functionality for captioning in order to have content presented to them. This includes people with

  • limited vision or without vision
  • cognitive limitation

Interpretation and specification of 3.1.2

The understanding article for the success criterion indicates that the requirement does not apply to words or expressions of a different linguistic origin to the surrounding text when the word or expression is commonly used in the language in which the page is written. Individual words are deemed to be part of the language of the text in which the word is included, unless it is clearly evident that the language has been changed deliberately. If there is any doubt as to whether such words and expressions have been used deliberately, a check should be carried out to find out whether the word or expression is pronounced in the same way as in the language in which the rest of the text is written.

Many disciplines use common international terms. The understanding article indicates that the requirement for coding of languages in parts of content does not apply to established specialist expressions or jargon that are borrowed from other languages.

Test procedures, content types and requirements for compliance with 3.1.2

Test procedure for success criterion 3.1.2:

  • 3.1.2a Content in a language other than the default language is coded correctly.

In the table below, we explain what content has been tested and what is defined as a criterion for the solution to be in accordance with the success criterion.

No.Test procedureTest objectHow to achieve compliance with the requirement
3.1.2aContent in a language other than the default language is coded correctly
  • Text content on web pages that is written in a language that is different to the default language for the page
  • For sentences or sections written in a language that is different to the default language for the web page, the following applies:
    • The component containing the sentence or section has a valid language code in the HTML code.
    • The language code corresponds to the language in which the sentence or section is written.

Success criterion 3.2.1 On focus

Purpose of 3.2.1

It must be predictable to the user what will happen when navigating a web page using a mouse or keyboard. Components that can be activated must not result in a change of context simply because they have received focus. The context must only be changed when the user actively executes an action, e.g. clicks on a link with a mouse or keyboard or presses a button.

Examples of context changes are opening a new window, moving focus to a different component, going to a new page or significantly re-arranging the content of a page.

Use situations for 3.2.1

This success criterion is primarily intended to take into account people with

  • limited vision or without vision
  • deaf-blindness
  • cognitive limitation
  • limited manipulation or strength

This requirement takes into account all users, in that it ensures more predictable use of web pages.

Interpretation and specification of 3.2.1

The requirement means that context changes of the types listed below must not be the result of a content component receiving focus. The WCAG glossary provides an extended explanation of what a context change is. Context change includes

  • changing the user agent (content is opened in another program)
  • changing the presentation frame
  • changing the focus and content in a way that changes the meaning of the web page

This requirement applies to both mouse and keyboard navigation. The Authority has restricted the verification to testing with a keyboard, as this has been deemed the most effective way of assessing predictable navigation. Standard implementation in HTML is such that error situations relating to focus that occur during keyboard navigation will generally occur when navigating with a mouse as well. Therefore, we have chosen to carry out the test with a keyboard for the purposes of efficiency.

Test procedures, content types and requirements for compliance with 3.2.1

Test procedure for success criterion 3.2.1:

  • 3.2.1a Keyboard focus does not cause a change of context.

In the table below, we explain what content has been tested and what is defined as a criterion for the solution to be in accordance with the success criterion.

No.Test procedureTest objectHow to achieve compliance with the requirement
3.2.1aKeyboard focus does not cause a change of context
  • Web pages with components that can receive focus. (Prerequisite: keyboard navigation is possible)
  • It is possible to navigate through the web page without a context change taking place when the various components receive focus

Success criterion 3.2.2 On input

Purpose of 3.2.2

The purpose of this requirement is that changes in user interface components do not result in context changes. Consequences of making changes to user interface components must be predictable and known to the user. Changing settings in user interface components includes, for example, checking a checkbox, selecting a radio button or inputting data, such as entering text in a form field. The user must be notified when such actions will involve changing the context.

Use situations for 3.2.2

This success criterion is intended to take into account users who are particularly dependent on interactive content being predictable. This includes people with

  • limited vision or without vision
  • deaf-blindness
  • cognitive limitation
  • limited manipulation or strength

Predictable navigation also enhances usability for all.

Interpretation and specification of 3.2.2

This requirement is that changes to settings in user interface components must not result in automatic context changes of the types listed below. The WCAG glossary provides an extended explanation of what a context change is. Context change includes

  • changing the user agent (content is opened in another program)
  • changing the presentation frame
  • changing the focus and content in a way that changes the meaning of the web page

If such context changes take place, the user must be advised before the component is used. Context changes that users must be advised of (and which are therefore relevant to this success criterion) are

  • opening new content in either the same tab, window or program or a new one
  • keyboard focus is moved to a different component on the web page
  • significant change in the meaning of the web page
  • form submission

This requirement applies to both mouse and keyboard navigation. The Authority has restricted the verification to testing with a keyboard, as this has been deemed the most effective way of assessing predictable navigation. Standard implementation in HTML is such that error situations relating to the setting of user interface components that are displayed during keyboard navigation will generally occur when navigating with a mouse as well. We have therefore chosen to carry out the test with a keyboard for the purposes of efficiency.

Test procedures, content types and requirements for compliance with 3.2.2

Test procedure for success criterion 3.2.2:

  • 3.2.2a Changing a setting in a form element does not cause a change of context.

In the table below, we explain what content has been tested and what is defined as a criterion for the solution to be in accordance with the success criterion.

No.Test procedureTest objectHow to achieve compliance with the requirement
3.2.2aChanging a setting in a form element does not cause a change of context
  • User interface components where the user changes settings. (Prerequisite: keyboard navigation is possible)
The requirement can be met in several different ways.
  • Changing settings in user interface components does not give automatic context changes
  • If changing settings in user interface components gives automatic context changes, the user must be notified in advance

Success criterion 3.2.3 Consistent navigation

Purpose of 3.2.3

The purpose of this success criterion is to encourage the use of consistent presentation of components for navigation on the website. Components that are repeated on multiple pages on a website must be presented consistently so that users can orient themselves easily. Clickable logos, search fields, menus, etc. are examples of navigational components.

Use situations for 3.2.3

This success criterion is primarily intended to take into account people with

  • limited vision or without vision
  • deaf-blindness
  • cognitive limitation

Consistent presentation of content components that appear on multiple pages on the website will also be user-friendly for everyone.

Interpretation and specification of 3.2.3

Navigation mechanisms that are available on multiple pages on the website must appear in the same relative order. Nevertheless, the requirement for consistent presentation (the same relative order) does not prevent components being inserted into or removed from the original order. In navigation menus that can be expanded, it is possible to add an extra level of detail or a secondary navigation element in the reading order, for example.

Test procedures, content types and requirements for compliance with 3.2.3

Test procedure for success criterion 3.2.3:

  • 3.2.3a Navigation elements in blocks are repeated in consistent order.

In the table below, we explain what content has been tested and what is defined as a criterion for the solution to be in accordance with the success criterion.

No.Test procedureTest objectHow to achieve compliance with the requirement
3.2.3aNavigation elements in blocks are repeated in consistent order
  • Navigation mechanisms in blocks that are repeated on multiple web pages
  • Blocks with navigation mechanisms that are repeated on multiple pages on the website appear in the same relative order on all the pages on which they are present

Success criterion 3.2.4 Consistent identification

Purpose of 3.2.4

Components that have the same functionality that are repeated in multiple locations on a website must have consistent identification in the code. This will make it easier for people who use screen readers to orient themselves and use the website. If identical components have different identification on different web pages, the website will be significantly more difficult to use. The search function is one example of the component covered by this success criterion.

Use situations for 3.2.4

This success criterion is primarily intended to take into account people with

  • limited vision or without vision
  • deaf-blindness
  • cognitive limitation

Consistent identification will also be user-friendly for everyone.

Interpretation and specification of 3.2.4

The requirement for consistent identification applies to components with the same functionality that are repeated

  • on multiple pages on a website
  • several times on the same page, and also on other pages

The requirement does not apply to components that are only present on one web page, even if they occur several times on a single page.

The fact that components with the same functionality have consistently formulated labels does not mean that the labels have to be identical. When, for example, links for scrolling through pages in a long document are formulated as follows: “Page 1”, “Page 2”, “Page 3”, they have the same functionality and are formulated consistently but are not identical in content.

The requirement covers a range of different component types, such as links, text alternatives to icons and images, toolbars, buttons in forms and the search function. To date the Authority has developed a test procedure for the search function. This component is present on many websites, can be formulated in many different ways and is also important for navigation.

Nevertheless, it is pointed out that the requirement also applies to other component types, and the Authority is considering developing more test procedures linked to this success criterion.

Test procedures, content types and requirements for compliance with 3.2.4

Test procedure for success criterion 3.2.4:

  • 3.2.4a The search function has consistent visual appearance and identification in the code.

In the table below, we explain what content has been tested and what is defined as a criterion for the solution to be in accordance with the success criterion.

No.Test procedureTest objectHow to achieve compliance with the requirement
3.2.4aThe search function has consistent visual appearance and identification in the code
  • Websites with a search function that is available on multiple pages
  • In the case of websites with a search function that is available on multiple pages, the search function has consistent visual appearance and identification in the code on all web pages

Success criterion 3.3.1 Error identification

Purpose of 3.3.1

When an error is made when filling in a form, the user must receive information to indicate both that an error has occurred and what the error is. The error message must be provided in the form of text and be as specific as possible. This also includes information on where in the form the error has occurred.

Use situations for 3.3.1

This success criterion is intended to make using forms easier for people with

  • limited vision or without vision
  • limited perception of colour
  • deaf-blindness
  • cognitive limitation

Identification and description of input errors in forms will also enhance usability for all users.

Interpretation and specification of 3.3.1

The success criterion relates to input errors that are detected automatically. Input errors include

  • information required by the web page but which the user has omitted (mandatory fields left blank)
  • information that is entered in the wrong data format, or the wrong value

Information that is entered must remain in the form even if an input error is identified. The purpose of this success criterion is to help the user fill in the form correctly, and in this case keeping the information in the form is an advantage. Nevertheless, the success criterion does not prevent automatic suggestion of corrections, cf. success criterion 3.3.3.

If a user enters a value that is too high, for example, and the value is automatically changed so that it falls within the permitted range, the user must nevertheless receive an error description. An error description that tells the user about the change of value will meet both success criterion 3.3.1 (Error identification) and 3.3.3 (Error suggestion).

Test procedures, content types and requirements for compliance with 3.3.1

Test procedures for success criterion 3.3.1:

  • 3.3.1a Form provides error messages if empty mandatory form fields are detected automatically.
  • 3.3.1b Form provides error messages if input errors are detected automatically.

In the table below, we explain what content has been tested and what is defined as a criterion for the solution to be in accordance with the success criterion.

No.Test procedureTest objectHow to achieve compliance with the requirement
3.3.1aForm provides error messages if empty mandatory form fields are detected automatically
  • Mandatory form elements
  • If it is detected automatically that mandatory form elements have not been filled in, the following applies:
    • The user receives an error message in text.
    • The error message is coded as text.
    • The error message identifies the form element where the error occurred.
    • The error message describes the error.
3.3.1bForm provides error messages if input errors are detected automatically
  • Form elements where input data errors are detected automatically
  • For all form elements where input data errors are detected automatically, the following requirements are met:
    • The user receives an error message in text.
    • The error message is coded as text.
    • The error message identifies the form element where the error occurred.
    • The error message describes the error.
    • With the exception of form elements with sensitive content, the information entered remains in the form element.

Success criterion 3.3.2 Labels or instructions

Purpose of 3.3.2

Form fields must have labels and instructions so that users understand how a form is to be filled in. This is intended to make it easier for users to use the form.

Use situations for 3.3.2

This success criterion is intended to take into account people with

  • limited vision or without vision
  • deaf-blindness
  • cognitive limitation
  • limited manipulation or strength

Labels and instructions also help make forms more user-friendly for everyone.

Interpretation and specification of 3.3.2

The requirement for labels or instructions applies to forms with more than one field. It is sufficient for labels and instructions to be displayed when the form field is in focus. The understanding article for the success criterion indicates that it is important to assess what information the user needs to be able to use the form. Too much information may make it difficult to get an overview of the content and understand it. However, this does not apply if the form only contains one field.

Success criteria 2.4.6 and 3.3.2 are closely interlinked:

  • 2.4.6 relates to both headings and labels. It does not require that they be provided, but states that if they are provided, they must be descriptive.
  • 3.3.2 requires that instructions or labels are provided that identify form elements (including whether the form element is mandatory) so that users know what input data is expected.

3.3.2 does not require that the relationship between the label and the form element can be programmatically determined. This is covered by success criteria 1.3.1 and 4.1.2.

Nor does 3.3.2 require error correction and help functionality in the form. This is covered by success criteria 3.3.1 and 3.3.3.

Form instructions that are images, are covered by success criteria 1.1.1 and 3.3.2. The test procedure for verification of these kinds of images is linked to success criterion 3.3.2, so that form instructions of this type are tested more comprehensively.

Test procedures, content types and requirements for compliance with 3.3.2

Test procedure for success criterion 3.3.2:

  • 3.3.2a Form elements have instructions or labels.

In the table below, we explain what content has been tested and what is defined as a criterion for the solution to be in accordance with the success criterion.

No.Test procedureTest objectHow to achieve compliance with the requirement
3.3.2aForm elements have instructions or labels
  • All components in digital forms, including a global search function
  • All form elements have labels or instructions that enable the user to use the form
  • The following requirements must be met:
    • The form element has a visual identification in the form of a label, instruction or icon, symbol or image.
    • The identification is visually positioned in or directly next to the form element.
    • The identification is always visible when the form element is in focus.
    • The icon, symbol or image is identified in the code.
    • Information is provided if the form element is mandatory, and any marking with a symbol is explained before it is used.

Success criterion 3.3.3 Error suggestion

Purpose of 3.3.3

The intent of this Success Criterion is to ensure that users receive appropriate suggestions for correction of an input error if it is possible. Prerequisites for this are that the error has been automatically detected and suggestions for correction are known. The purpose is to allow the user to use digital forms more easily.

Use situations for 3.3.3

This success criterion is intended to take into account people who may need help to be able to use forms effectively. This includes people with

  • limited vision or without vision
  • limited perception of colour
  • deaf-blindness
  • cognitive limitation
  • limited manipulation or strength

Suggested corrections of input errors in forms will also enhance usability for all users.

Interpretation and specification of 3.3.3

This requirement applies to form solutions in which errors in input data are detected automatically. This is information provided by the user and includes

  • information required by the web page but which the user has omitted (mandatory fields left blank)
  • information that is provided but is in the wrong format or has the wrong value

The Authority also assumes, given success criterion 3.3.1, that information entered, or a suggested correction, must remain in the form element after the error has been detected automatically. This is because the purpose of this success criterion is to help the user to fill in the form correctly, and in this case the information or the suggested correction remaining in the form is an advantage.

The requirement does not apply if

  • there are no exact or known ways to correct the error, e.g. spelling, how to write a name, etc.
  • the input data is linked to security, e.g. a password
  • a suggested correction would undermine the purpose, e.g. an answer to a quiz

Test procedures, content types and requirements for compliance with 3.3.3

Test procedure for success criterion 3.3.3:

  • 3.3.3a Form provides suggestions for correction if input errors are detected automatically.

In the table below, we explain what content has been tested and what is defined as a criterion for the solution to be in accordance with the success criterion.

No.Test procedureTest objectHow to achieve compliance with the requirement
3.3.3aForm provides suggestions for correction if input errors are detected automatically
  • Form elements where input data errors are detected automatically
  • For all form elements where input data errors are detected automatically, the user receives a suggestion that provides sufficient information on how the error can be corrected

Success criterion 3.3.4 Error prevention

Purpose of 3.3.4

Allowing the user to check data and correct errors when filling in a form can prevent errors having serious consequences. Serious consequences can also be prevented if the user has the opportunity to confirm information or reverse actions.

Use situations for 3.3.4

Functionality for preventing errors that users may make when using forms and that will have serious consequences of a legal or financial nature helps all users, with and without disabilities.

Interpretation and specification of 3.3.4

The requirement is restricted to transactions that involve legally binding obligations or rights for the user. This may, for example, include ticket purchases, bank transactions, information in profiles in various data storage systems, etc.

At least one of the three options listed below must be provided in the form process:

  • Form submission can be reversed.
  • Data can be checked and corrected.
  • There is a mechanism for review, confirming and correcting information prior to submission.

Test procedures, content types and requirements for compliance with 3.3.4

Test procedures for success criterion 3.3.4:

  • 3.3.4a In forms that cause commitments or transactions, the user can check and edit information, or undo submission.
  • 3.3.4b The user can confirm or undo deletion of saved information.

In the table below, we explain what content has been tested and what is defined as a criterion for the solution to be in accordance with the success criterion.

No.Test procedureTest objectHow to achieve compliance with the requirement
3.3.4aIn forms that cause commitments or transactions, the user can check and edit information, or undo submission
  • Forms that involve legal and/or financial obligations for the user
  • Forms that edit or delete userdefined data in data storage systems
  • Forms that send responses to tests completed by the user
The requirement can be met in several different ways:
  • It must be possible to
    • either review and edit before submission, or
    • undo submission of forms that could result in serious consequences
  • One of the following requirements must be met:
    • 1. Before submission, the user receives
      • a request to review the information entered
      • the opportunity to edit all information prior to submission
      • a request to confirm that the information is correct
    • 2. After submission,
      • the user receives notification of how they can undo form submission and
      • that undoing submission is possible
3.3.4bThe user can confirm or undo deletion of saved information
  • Forms that delete userdefined data in data storage systems
The requirement can be met in several different ways:
  • It must be possible to
    • either confirm deletion, or
    • undo after deletion of saved information from a form that could result in serious consequences
  • One of the following requirements must be met:
    • 1. Before deletion, the user is asked to confirm that they want to delete the information.
    • 2. After submission, it is possible to undo the deletion.

Success criterion 4.1.1 Parsing

Purpose of 4.1.1

The purpose of this success criterion is to ensure that the correct code syntax is used so that web pages behave predictably and reliably in different user agents such as browsers, screen readers and assistive technologies.

If the content has the wrong code syntax, various user agents and assistive devices may interpret and present the content in different ways, or not be able to interpret the content at all.

Use situations for 4.1.1

People who use assistive technologies are dependent on web pages not including syntax errors so as to ensure that the content is presented correctly. This includes people with

  • limited vision or without vision
  • deaf-blindness
  • cognitive limitation

Interpretation and specification of 4.1.1

Interpretation of the success criterion reflects that the Authority uses the W3C HTML validator when we verify whether web solutions are formulated in compliance with 4.1.1. It is a requirement pursuant to this success criterion that web pages must not contain the following errors:

  • Elements with incomplete start and end tags.
  • Elements that are not nested in compliance with the specifications.
  • Elements that contain duplicate attributes.
  • Elements that have non-unique IDs.

In some cases, it is not possible to validate the entire web page. In these cases, the validator stops and returns the result “Fatal error”. If the code contains a fatal error, the success criterion is assessed as not met.

According to the wording of the success criterion, the requirement does not apply if it is specified that the markup language used in the web solution permits the situations listed in the bulleted list above. The Authority’s test procedure for this success criterion prepares for the testing of web pages coded in HTML and XHTML. These markup languages do not have such exceptions.

Test procedures, content types and requirements for compliance with 4.1.1

Test procedure for success criterion 4.1.1:

  • 4.1.1a The code does not contain syntax errors.

In the table below, we explain what content has been tested and what is defined as a criterion for the solution to be in accordance with the success criterion.

No.Test procedureTest objectHow to achieve compliance with the requirement
4.1.1aThe code does not contain syntax errors
  • Content coded in HTML or XHTML
  • The web page does not have a “Fatal Error” on validation and does not include syntax errors of the following types:
    • Elements with incomplete start and end tags.
    • Elements that are not nested in compliance with the specifications.
    • Elements that contain duplicate attributes.
    • Elements that have non-unique IDs.

Success criterion 4.1.2 Name, role, value

Purpose of 4.1.2

The purpose of this success criterion is to make user interface components, such as form elements and buttons, accessible to people who use assistive technologies.

Use situations for 4.1.2

This success criterion is intended to take into account users who rely on assistive technology such as screen readers, screen magnifiers and speech recognition software to access content on web pages. This includes people with

  • limited vision or without vision
  • deaf-blindness
  • limited manipulation or strength Interpretation and specification of 4.1.2

In WCAG, user interface components are defined as a part of the content that users perceive as a separate control component with a specific function. The requirement is for these kinds of user interface components to be identified with names and roles in the code. Names are text that software can use to identify the component itself. Roles are text or numbers that software uses to identify the function of a component.

Assistive technologies must be able to

  • find information about the components
  • enable or disable the components
  • stay up to date if the components’ settings change

The understanding article indicates that the requirement is met if all user interface components are compliant with the specification for the technology in which the web page is coded. If custom components have been created, or standard components have been 66 programmed (in code or script) to have a different role and/or function than usual, information must be provided about the component’s name, role and value.

The success criterion applies to all user interface components, such as form elements, links, buttons and iframe elements. The Authority’s test procedures for this success criterion cover form elements, buttons and iframe elements.

Test procedures, content types and requirements for compliance with 4.1.2

Test procedures for success criterion 4.1.2:

  • 4.1.2a Form elements are identified in the code.
  • 4.1.2b Buttons are identified in the code.
  • 4.1.2c Iframes are identified in the code.

In the table below, we explain what content has been tested and what is defined as a criterion for the solution to be in accordance with the success criterion.

No.Test procedureTest objectHow to achieve compliance with the requirement
4.1.2aForm elements are identified in the code
  • Form elements such as checkboxes, radio buttons, text fields or drop-down lists
  • Form elements are linked to a label in the code. There are several ways of doing this. The label identifies the form element
  • If the form element belongs to a group, it is also linked to a label that applies to the group. The label identifies the group
4.1.2bButtons are identified in the code
  • Buttons for enabling a function or submitting a form, for example
  • Buttons that comprise images, coded as links, div, span, etc.
  • Buttons are linked to a label in the code. There are several ways of doing this. The label identifies the function of the button
  • Buttons that are not coded with standard components in (X)HTML must have information about their roles
4.1.2cIframes are identified in the code
  • Iframe elements
  • If an iframe element is used in the code, the iframe element has a label that identifies the content

5.5 Key indicators for area surveillance

The Authority’s has test procedures for verification of all the success criteria in WCAG 2.0 that are mandatory pursuant to the Norwegian regulations. It is nevertheless seldom relevant to verify ICT solutions against all the success criteria. We select a sample both in audits and large scale monitoring.

For the purpose of monitoring, we have identified a set of key indicators that cover a selection of the success criteria in WCAG 2.0. The selection is based on criteria listed below:

  • The four main principles in WCAG 2.0.
  • Different use situations and user groups.
  • The most important types of content and properties of the web solutions.
  • The most important areas of risk identified in previous monitoring and audits.

The success criteria that form the basis of the key indicators are shown in the table below.

No.Success criterionIndicator
11.1.1
  • Image has a text alternative
  • The purpose of a linked image is explained by a link text and/or text alternative
21.2.2
  • Prerecorded video with sound has captions
31.3.1
  • Headings are coded correctly
  • Tables and header cells are coded correctly
  • Lists are coded correctly
41.4.1
  • Links are distinguishable from other text by means other than colour alone
51.4.2
  • It is possible to control sound that starts automatically and does not stop within 3 seconds
61.4.3
  • There is sufficient contrast between text and its background
71.4.4
  • Text can be enlarged to at least 200 % without loss of content or functionality
82.1.1
  • Content and functionality is operable through a keyboard
92.1.2
  • There are no keyboard traps on the web page
102.4.4
  • The purpose of the links is conveyed by the link text, or the link text together with the context
112.4.6
  • Headings describe the content
122.4.7
  • Content that is keyboard operable has a visual focus indicator
133.3.1
  • Form returns an error message when empty obligatory form fields are automatically detected
143.3.2
  • Form elements have instructions or labels
154.1.1
  • The code does not contain syntax errors
164.1.2
  • Form elements are identified in the code
  • Buttons are identified in the code

The key indicators are intended to provide a reasonably good overview of the status of universal design. The key indicators cover 16 of the 35 success criteria in WCAG 2.0, that are referred to in the Norwegian regulations.

We find that the key indicators provide a good basis for monitoring status, where we verify a relatively large volume of web solutions.

The key indicators can be a fixed basis for all large scale monitoring.

6. Appendix: Categorisation of success criteria and test procedures

Appendix 2 contains tables that provide an overview of a sample of metadata that indicate what topic each individual success criterion and test procedure can be linked to, specified by content type, structural element and functionality. The overview also shows what use situations and user groups the individual success criterion is intended to take into account.

A more detailed account of this is provided in section chapter 5.8 on the data model. We use this type of metadata both to 1) identify which test procedures to apply within each topic and 2) in analysis of the test results. This enables us to identify digital barriers and show the consequences of inadequate universal design for different user groups.

The categorisation is presented in the tables below.

Topic and test object

The table provides an overview of the test procedures and the topic being tested, including an overview of the test object in each test procedure.

No.Test procedureCategory or topicTest object
11.1.1a Image has a text alternativeAlternative formatImages and illustrations
21.1.1b The purpose of a linked image is explained by a link text and/or text alternativeAlternative formatImages and illustrations
31.1.1c The purpose of selectable regions in image maps is explained by a text alternativeAlternative formatImages and illustrations
41.1.1d CAPTCHA has a text alternative and an alternative formAlternative formatCAPTCHA
51.2.1a Prerecorded audio-only content has a text alternativeAlternative formatMedia content
61.2.1b Prerecorded video-only has a text alternative or audio alternativeAlternative formatMedia content
71.2.2a Prerecorded video with audio has captionsAlternative formatMedia content
81.3.1a Headings are coded correctlyCodeHeadings
91.3.1b Tables and header cells are coded correctlyCodeTables
101.3.1c Lists are coded correctlyCodeLists
111.3.2a Meaningful reading order is programmatically determinedNavigationWeb page (content unspecified)
121.3.3a Instructions for use of forms are not solely dependent on sensory characteristicsUse of formsForms
131.4.1a Links are distinguishable from other text by means other than colour aloneNavigationLinks
141.4.1b Information in graphic representations is distinguishable by means other than colour aloneNavigationImages and illustrations
151.4.1c Form elements and error messages are marked by means other than colour aloneUse of formsForms
161.4.2a Control of audio that starts automatically and does not stop within 3 secondsNavigationMedia content
171.4.3a There is sufficient contrast between text and its backgroundNavigationText
181.4.3b There is sufficient contrast between text and its background in an image of textNavigationImages and illustrations
191.4.3c There is sufficient contrast between text and its background (automated test)NavigationText
201.4.4a Text can be enlarged to at least 200% view with no loss of content or functionalityNavigationText
211.4.5a Image of text is not used unnecessarilyNavigationImages and illustrations
222.1.1a Functionality of the content is operable through a keyboardKeyboard operationAll user interface components
232.1.2a There are no keyboard traps on the web pageKeyboard operationAll user interface components
242.2.1a It is possible to turn off, adjust or extend time limitsNavigationTime limits
252.2.2a It is possible to pause, stop or hide content that moves, blinks or scrollsNavigationContent that blinks and/or auto-updates
262.2.2b It is possible to pause, stop, hide or change the update frequency for autoupdating contentNavigationContent that blinks and/or auto-updates
272.3.1a The web page has no flashing contentNavigationContent that blinks and/or auto-updates
282.4.1a There is a mechanism for skipping to the primary content on the web pageKeyboard operationNavigation mechanisms
292.4.2a The web page has a descriptive page titleNavigationPage title
302.4.3a Keyboard focus order preserves meaning and operabilityKeyboard operationWeb page (content unspecified)
312.4.4a The purpose of each link can be determined from the link text alone or the link text together with its contextNavigationLinks
322.4.5a There are multiple ways to navigateNavigationNavigation mechanisms
332.4.6a Headings describe the contentNavigationHeadings
342.4.6b Form elements have descriptive labelsUse of formsForms
352.4.7a Keyboard operable content has a visual focus indicatorKeyboard operationAll user interface components
363.1.1a The default language of the web page is coded correctlyCodeWeb page (content unspecified)
373.1.2a Content in a language other than the default language is coded correctlyCodeWeb page (content unspecified)
383.2.1a Keyboard focus does not cause a change of contextKeyboard operationWeb page (content unspecified)
393.2.2a Changing a setting in a form element does not cause a change of contextKeyboard operationForms
403.2.3a Navigation elements in blocks are repeated in consistent orderNavigationNavigation mechanisms
413.2.4a The search function has consistent visual appearance and identification in the codeNavigationNavigation mechanisms
423.3.1a Form provides error messages if empty mandatory form fields are detected automaticallyUse of formsForms
433.3.1b Form provides error messages if input errors are detected automaticallyUse of formsForms
443.3.2a Form elements have instructions or labelsUse of formsForms
453.3.3a Form provides suggestions for correction if input errors are detected automaticallyUse of formsForms
463.3.4a In forms that cause commitments or transactions, the user can check and edit information, or undo submissionUse of formsForms
473.3.4b The user can confirm or undo deletion of saved informationUse of formsForms
484.1.1a The code does not contain syntax errorsCodeSource code
494.1.2a Form elements are identified in the codeCodeForms
504.1.2b Buttons are identified in the codeCodeForms
514.1.2c Iframes are identified in the codeCodeIframe

Use situations

The table gives an overview of which use situations the success criteria are meant to specifically benefit.

Success criterionWithout visionLimited visionLimited perception of colourDeafblindnessWithout hearingLimited hearingCognitive limitationLimited manipulation or strengthSeizure disorderAll users
1.1.1 Non-text contentYesYes YesYesYesYes  Yes
1.2.1 Audioonly and video-only (pre-recorded)YesYes YesYesYes    
1.2.2 Captions (pre-recorded)    YesYes   Yes
1.3.1 Info and relationshipsYes  Yes      
1.3.2 Meaningful sequenceYesYesYes       
1.3.3 Sensory characteristicsYesYesYes       
1.4.1 Use of colourYesYes       Yes
1.4.2 Audio control YesYes      Yes
1.4.3 Contrast YesYes      Yes
1.4.4 Resize text Yes       Yes
1.4.5 Images of textYesYes    Yes   
2.1.1 Access everything with a keyboardYesYes     Yes  
2.1.2 No keyboard trapYesYes     Yes  
2.2.1 Timing adjustableYesYes YesYes YesYes Yes
2.2.2 Pause, stop, hide      Yes  Yes
2.3.1 Three flashes or below threshold        Yes 
2.4.1 Bypass blocksYesYes Yes  YesYes  
2.4.2 Page titled Yes    YesYes Yes
2.4.3 Focus orderYesYes Yes  YesYes  
2.4.4 Link purpose (in context)YesYes Yes  YesYes Yes
2.4.5 Multiple waysYesYes Yes  YesYes Yes
2.4.6 Headings and labelsYesYes Yes  YesYes Yes
2.4.7 Focus visible Yes    YesYes  
3.1.1 Language of the pageYesYes    Yes   
3.1.2 Language of partsYesYes    Yes   
3.2.1 On focusYesYes Yes  YesYes Yes
3.2.2 On inputYesYes Yes  YesYes Yes
3.2.3 Consistent navigationYesYes Yes  Yes  Yes
3.2.4 Consistent identificationYesYes Yes  Yes  Yes
3.3.1 Error identificationYesYesYesYes  Yes  Yes
3.3.2 Labels or instructionsYesYes Yes  YesYes Yes
3.3.3 Error suggestionYesYesYesYes  YesYes Yes
3.3.4 Error prevention (legal, financial, data)         Yes
4.1.1 ParsingYesYes Yes  Yes   
4.1.2 Name, role, valueYesYes Yes   Yes  

7. References

Sharethis

Fant du det du lette etter?

Stjerne(*) er obligatoriske felter som du må fylle ut for å sende skjemaet. 

MERK: Du får ikke svar på denne meldingen. Har du spørsmål du ønsker svar på send oss en e-post til uu@difi.no.

Fant du det du lette etter?
*