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

1. Introduction and background

The Norwegian Digitalisation Agency 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.

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.

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.

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.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:

• Accessibility Conformance Testing (ACT) Rules Format 1.0.
• Website Accessibility Conformance Evaluation Methodology (WCAG-EM) 1.0.
• Evaluation and Report Language (EARL) 1.0 Schema.

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.

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

• the wording of each individual success criterion
• the articles in WCAG with information about how we are to understand and comply with the success criteria
• the informative documents of Techniques and Failures for Web Content Accessibility Guidelines 2.0, which provides a basis for determining whether a web solution is in compliance with WCAG 2.0

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.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.

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.

• A selection of test procedures that form the basis of the supervision's area monitoring can be downloaded here.
• The complete set of indicators/test procedures (in Norwegian) can be downloaded here (Zip file).

5.1 PRINCIPLE: PERCEIVABLE

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

5.2 PRINCIPLE: OPERABLE

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

5.3 PRINCIPLE: UNDERSTANDABLE

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

5.4 PRINCIPLE: ROBUST

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.

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.

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.

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.

Use situations

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

7. References

• Regulation on universal design of information and communication technology (ICT) solutions (FOR-2013-06-21-732)
• Web Content Accessibility Guidelines (WCAG) 2.0 (W3C, 2011)
• Understanding WCAG 2.0 (W3C, 2016)
• Techniques for WCAC 2.0 (W3C, 2016)
• Website Accessibility Conformance Evaluation Methodology (WCAG-EM) 1.0 (W3C, 2014)
• Accessibility Conformance Testing Framework Requirements (W3C, 2017)
• Evaluation and Report Language (EARL) 1.0 Schema (W3C, 2017)
• The Authority for Universal Design of ICT. Strategy 2017 – 2020 (Digdir, 2017)
• Digital barriers on Norwegian websites. Status report on the universal design of websites in the private and public sector – 2014 (Difi-report 2015:7)
• Store norske leksikon (The Great Norwegian Encyclopedia)
• The use of ICT in households, Statistics Norway (2017)
• The population survey 2015, (Digdir, 2015)
• Documentation on the Authority’s data model for universal design of ICT (Digdir, Authority for Universal Design of ICT, 2018)
• DIRECTIVE (EU) 2016/2102 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 26 October 2016 on the accessibility of the websites and mobile applications of public sector bodies