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

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

Content

    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:

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

    The elements in the method are listed below.

    Interpretation of WCAG 2.0

    • What is the purpose of the success criteria?
    • What content or functionality do the success criteria apply to?
    • Which use situations are the success criteria intended to take into account?
    • What must be met for the test to indicate compliance (or non-compliance) with the success criteria?

    Test procedures

    • Step-by-step description of the test procedure.
    • Standardised template for registering test data.
    • Automatic generation of pre-defined (descriptive, text-based) test results, based on registered test data.

    Scale for test results

    • A scale for an overview of how many test objects that comply or not comply with the success criteria.
    • A scale for an overview of how many success criteria have been complied or noncomplied with.

    Data model

    • Quantitative test results, graded scale and percentage, suitable for detailed overviews, aggregated statistics and analysis.
    • Metadata, about ICT solutions and organisations that are responsible for the solutions.
    • Export of data for audit reports, statistics and analysis.

    2.3.1 Interpretation of the success criteria in WCAG 2.0

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

    The Authority’s interpretation of success criteria is based on

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

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

    2.3.2 Test procedures and categories of test results

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

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

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

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

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

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

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

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

    Test (success criterion)

    Number of test objects Number of compliant test objects Number of non-compliant test objects Points (number of success criteria fully complied with) Percentage score (percentage of tests that show compliance)
    1.1.1a 15 images 5 images 10 images 0 points 33%
    1.3.1a 20 headings 20 headings 0 headings 1 point 100%
    3.3.2a 18 labels 16 labels 2 labels 0 points 89%

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

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

    2.3.4 Data model for analysis

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

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

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

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

    Category Example of type of content or functionality
    Alternative format

    Text alternative for images and other non-text content, Video captions

    Use of forms

    Instructions and labels, Error messages, Possibility to modify or undo submission of forms that cause commitments, transactions or delete user data. which provides obligations for the user, Change of context

    Content markup

    Headings, Tables, Lists, Form elements and buttons, Iframe, Language of page and other parts of the content, Code syntax

    Navigation

    Meaningful sequence, Visual identification of links, purpose of links, Use of colour, Audio control, Contrast between text and its background, Resizing of text, Images of text, Time limits, Pause/stop/hide, Content that flashes, Descriptive page titles and headings, Multiple navigation mechanisms, Consistent navigation and identification

    Keyboard operation

    Functionality is operable, Keyboard trap, Shortcut skip link, Keyboard focus order, Visual focus indicator, Change of context on focus

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

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

    The data model shall serve several purposes:

    Using the metadata on content types and functionality, we can identify what test procedures we need to verify, for example, forms. Similarly, we will use the same data model to analyse the test data, and evaluate the degree of compliance or non-compliance with the regulations for all the forms included in a measurement.

    By linking the test data from the verification of the solutions to information about which sector of society the organisations responsible for the solutions belong to, we can uncover digital barriers on different areas of society.

    Using metadata that shows the different use situations that the success criteria are intended to take into account, we get information regarding the consequences of lack of universal design.

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

    3. Selection of web solutions and test pages for monitoring

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

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

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

    3.1 Selection of web solutions

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

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

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

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

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

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

    3.2 Selection of test pages

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

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

    We put together a sample based on the following criteria:

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

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

    4. Web Content Accessibility Guidelines (WCAG)

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

    The four principles of WCAG 2.0 are:

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

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

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

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

    5. Interpretation of WCAG 2.0 and associated test procedures

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

    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.

    No. Test procedure Test object How to achieve compliance with the requirement
    1.1.1a Image has a text alternative

    Non-linked image that is purely decorative, sensory experiences, meaningful or complex

    Images that are purely decorative are coded in such a way that they do not cause confusion

    Images that are a sensory experience or test have a short text alternative that provides a descriptive identification

    Images that are meaningful have a short text alternative that provides the same information as the image

    Images that are complex have both a short and a supplementary text alternative that provides the same information as the image

    1.1.1b The purpose of a linked image is explained by a link text and/or text alternative

    Linked image

    The requirement can be met in several different ways.For linked images, information on the link target is provided by one of the following alternatives:

    The link text.

    The text alternative for the image.

    The link text and the text alternative for the image together.

    1.1.1c The purpose of selectable regions in image maps is explained by a text alternative

    Image map with clickable areas

    For clickable areas in image maps, information on the link target is provided by the text alternative

    1.1.1d CAPTCHA has a text alternative and an alternative form

    CAPTCHA in the form of an image, sound or logical task

    If CAPTCHAs with non-text content are used, the following requirements are met:

    There are at least two types of CAPTCHA, e.g. in the form of an image, sound or text.

    Non-text content has a text alternative that identifies and describes the purpose.

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

    Purpose of 1.2.1

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

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

    Use situations for 1.2.1

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

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

    Interpretation and specification of 1.2.1

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

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

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

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

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

    Test procedures, content types and requirements for compliance with 1.2.1

    Test procedures for success criterion 1.2.1:

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

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

    No. Test procedure Test object How to achieve compliance with the requirement
    1.2.1a Prerecorded audio-only content has a text alternative

    Prerecorded audio

    The requirement can be met in several different ways.

    Prerecorded audio that is not a media alternative to text or video has an alternative in the form of text

    The text alternative

    is visually positioned near to the audio clip, or

    can be accessed via a mechanism (link, button or similar) close to the audio clip

    In both cases, the text alternative must

    be coded as text and

    convey the same primary content as the audio clip, in the same order

    Precise reproduction of the content is not required, but all essential content must be included in the correct order

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

    Prerecorded video without audio

    The requirement can be met in several different ways.

    Prerecorded video without audio, which is not a media alternative to text or audio, has an alternative in the form of text or audio

    The alternative in the form of text or audio

    is visually positioned near to the video clip, or

    can be accessed via a mechanism (link, button or similar) close to the video clip

    conveys the same primary content as the video clip, in the same order

    Alternatives in the form of sound must also

    be possible to play back

    Alternatives in the form of text must also

    be coded as text

    Precise reproduction of the content is not required, but all essential content must be included in the correct order

    Success criterion 1.2.2 Captions (prerecorded)

    Purpose of 1.2.2

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

    Use situations for 1.2.2

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

    • limited hearing or without hearing

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

    Interpretation and specification of 1.2.2

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

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

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

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

    Test procedures, content types and requirements for compliance with 1.2.2

    Test procedure for success criterion 1.2.2:

    • 1.2.2a Prerecorded video with sound has captions.

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

    No. Test procedure Test object How to achieve compliance with the requirement
    1.2.2a Prerecorded video with sound has captions

    Prerecorded video with audio

    The requirement can be met in several different ways.

    Prerecorded video with audio that is not a media alternative to text or video has an alternative in the form of captions or a text alternative

    Captions that either are permanent (open captions) or can be enabled (closed captions) must

    convey the content of audio and video

    contain the following components: speech and dialogue, indicating who is speaking, and audio content that is important in order to understand the video

    be visible but not disrupt important content in the video

    Text alternative, alternatively the video can have a text alternative that is visually positioned close to the video clip or can be accessed via a mechanism (link, button or similar)

    The text alternative must

    be coded as text

    convey the content of audio and image, and contain the following components: speech and dialogue indicating who is speaking, and audio content that is important in order to understand the video

    Precise reproduction of the content is not required, but all essential content must be included in the correct order

    Success criterion 1.3.1 Info and relationships

    Purpose of 1.3.1

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

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

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

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

    Use situations for 1.3.1

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

    • people without vision
    • people with deaf-blindness

    Interpretation and specification of 1.3.1

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

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

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

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

    Test procedures, content types and requirements for compliance with 1.3.1

    Test procedures for success criterion 1.3.1:

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

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

    No. Test procedure Test object How to achieve compliance with the requirement
    1.3.1a Headings are coded correctly

    Visual headings

    Hierarchy of visual headings

    Visual headings are coded as headings

    Headings that are included in a visual heading hierarchy are coded with the correct heading level

    1.3.1b Tables and header cells are coded correctly

    Tables (information structured in rows and columns)

    The following content in tables is coded semantically correctly:

    Table caption.

    Header cells in tables with headings in just one row or column.

    Header cells in tables with headings in both a column and a row.

    Header cells in tables with headings on several rows and/or columns inside the table.

    1.3.1c Lists are coded correctly

    Visual lists (grouped information, marked with bullet points or numbers, for example)

    Visual lists are coded as follows:

    Ordered lists are coded as ordered lists.

    Unordered lists are coded as unordered lists.

    Description lists (lists that have two levels and provide supplementary explanations) are coded as description lists.

    Success criterion 1.3.2 Meaningful sequence

    Purpose of 1.3.2

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

    Use situations for 1.3.2

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

    • limited vision or without vision
    • deaf-blindness

    Interpretation and specification of 1.3.2

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

    Examples of meaningful sequences include

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

    Unordered lists are not deemed to be a meaningful sequence.

    The understanding article otherwise specifies the following:

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

    Test procedures, content types and requirements for compliance with 1.3.2

    Test procedure for success criterion 1.3.2:

    • 1.3.2a Meaningful reading order is programmatically determined.

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

    No. Test procedure Test object How to achieve compliance with the requirement
    1.3.2a Meaningful reading order is programmatically determined

    Content that is presented in a meaningful order

    The requirement can be met in several different ways

    The reading order of content in a display with CSS disabled, compared with standard display, is either

    the same

    a reading order that otherwise presents the same meaning of the content

    Success criterion 1.3.3 Sensory characteristics

    Purpose of 1.3.3

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

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

    Use situations for 1.3.3

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

    • limited vision or without vision
    • deaf-blindness

    Interpretation and specification of 1.3.3

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

    Clarifications:

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

    Test procedures, content types and requirements for compliance with 1.3.3

    Test procedure for success criterion 1.3.3:

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

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

    No. Test procedure Test object How to achieve compliance with the requirement
    1.3.3a Instructions for use of forms are not solely dependent on sensory characteristics

    Instructions in forms that include references to sensory characteristics

    The requirement can be met in several different ways.

    Instructions that include information on components’ sensory characteristics (shape, size, visual position on the page, orientation or sound) also include other information that allows the user to find and use the component

    This requirement may also be met if any of the following are observed

    in the instruction, words are used that are natural in the language to refer to a reading order and the same reading order is observed in the code

    the instruction is provided in the form of a symbol, icon or graphic representation, and this is identified in the code

    Success criterion 1.4.1 Use of colour

    Purpose of 1.4.1

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

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

    Use situations for 1.4.1

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

    • limited vision or without vision
    • limited perception of colour

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

    Interpretation and specification of 1.4.1

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

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

    Test procedures, content types and requirements for compliance with 1.4.1

    Test procedures for success criterion 1.4.1:

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

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

    No. Test procedure Test object How to achieve compliance with the requirement
    1.4.1a Links are distinguishable from other text by means other than colour alone

    Links in running text (not in menus)

    Linked headings

    The requirement can be met in several different ways.Links in running text are compliant with one of the alternatives below:

    Links that are marked with colour are distinguished from adjacent non-link text by means other than colour alone, e.g. font type, font size, underlining, bold type, frames or icons.

    Links that are marked with colour alone have a contrast of at least 3:1 to adjacent non-link text and have visible marking by means other than colour alone in the case of both mouseover and keyboard focus. Changing the cursor and standard focus indicator when navigating using a keyboard are not sufficient marking.

    1.4.1b Information in graphic representations is distinguishable by means other than colour alone

    Graphic representations, e.g.: diagrams, organisational charts, graphic representations of transport systems and similar.

    The requirement can be met in several different ways.If colour is used as a visual instrument for conveying information or distinguishing visual components in graphic representations, one of the following requirements is also met:

    Explanatory text or other visual instruments that provide the same information conveyed by use of colour. Example: pattern, shape (e.g. star, diamond, square, etc.) or a direct link between part of the illustration where colour is used and explanatory information.

    There is a mechanism that activates such information.

    1.4.1c Form elements and error messages aremarked by means other than colour alone

    Use of colour in form elements, instructions and error messages

    Form elements, instructions and error messages that use colour to

    convey information

    show an action

    request a response

    or distinguish a visual component

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

    Success criterion 1.4.2 Audio control

    Purpose of 1.4.2

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

    Use situations for 1.4.2

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

    • limited vision or without vision

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

    Interpretation and specification of 1.4.2

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

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

    Test procedures, content types and requirements for compliance with 1.4.2

    Test procedure for success criterion 1.4.2:

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

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

    No. Test procedure Test object How to achieve compliance with the requirement
    1.4.2a Control of audio that starts automatically and does not stop within 3 seconds

    Web pages with audio that starts automatically and does not stop within three seconds

    Audio that starts automatically and does not stop within 3 seconds has a mechanism for audio control that

    is visually positioned near the start of the page

    can be operated with a keyboard

    is early in the tab order sequence (maximum 5 tab steps)

    has a visual marker in the form of text or a symbol

    Success criterion 1.4.3 Contrast

    Purpose of 1.4.3

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

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

    Use situations for 1.4.3

    The success criterion takes into account people with

    • limited vision
    • limited perception of colour

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

    Interpretation and specification of 1.4.3

    The success criterion indicates that the contrast requirement

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

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

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

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

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

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

    Test procedures, content types and requirements for compliance with 1.4.3

    Test procedures for success criterion 1.4.3:

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

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

    No. Test procedure Test object How to achieve compliance with the requirement
    1.4.3a There is sufficient contrast between text and its background

    Text in the form of headings, links and other text, labels, help texts or error messages in forms, illustrations and diagrams (that are not images)

    The requirement can be met in several different ways.1. Text has contrast

    of at least 4.5:1 to the background

    of at least 3.0 to the background and the text size is at least 24 pixels, or 19 pixels bold

    2. There is a high-contrast version that meets the following requirements:

    The mechanism for activation is positioned close to the start of the page and is visually marked with a text or icon.

    The mechanism meets the contrast requirement in point 1 above.

    Text in the high-contrast version meets the contrast requirement in point 1 above.

    The textual component measured with inadequate contrast in ordinary view is identical to the component in the highcontrast version.

    1.4.3b There is sufficient contrast between textand its background in an image of text

    Images of text

    The requirement can be met in several different ways.

    1. Image of text has contrast of at least 3:1 to the background

    2. There is a high-contrast version that meets the following requirements:

    The mechanism for activation is positioned close to the start of the page and is visually marked with a text or icon.

    The mechanism has contrast of at least 4.5:1.

    Text in the high-contrast version meets the contrast requirement in point 1 above.

    The textual component measured with inadequate contrast in ordinary view is identical to the component in the highcontrast version.

    1.4.3c There is sufficient contrast between text and its background (automated test)

    Text in the form of headings, links and other text, labels, help texts or error messages in forms, illustrations and diagrams (that are not images)

    Text has contrast of at least 4.5:1 to the background

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

    Success criterion 1.4.4 Resize text

    Purpose of 1.4.4

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

    Use situations for 1.4.4

    The success criterion takes into account people with

    • limited vision

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

    Interpretation and specification of 1.4.4

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

    Test procedures, content types and requirements for compliance with 1.4.4

    Test procedure for success criterion 1.4.4:

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

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

    No. Test procedure Test object How to achieve compliance with the requirement
    1.4.4a Text can be enlarged to at least 200 % view with no loss of content or functionality

    Text that is not captions in video or images of text

    Text in form elements

    All text can be enlarged to at least 200 % view without any loss of content or functionality

    Success criterion 1.4.5 Images of text

    Purpose of 1.4.5

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

    Use situations for 1.4.5

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

    • limited vision or without vision
    • cognitive limitation

    Interpretation and specification of 1.4.5

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

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

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

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

    Test procedures, content types and requirements for compliance with 1.4.5

    Test procedure for success criterion 1.4.5:

    • 1.4.5a Image of text is not used unnecessarily.

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

    No. Test procedure Test object How to achieve compliance with the requirement
    1.4.5a Image of text is not used unnecessarily

    Images of text

    The requirement can be met in several different ways.Image of text is not used unless:

    image of text can be adapted to the user’s requirements or

    image of text is necessary to present information

    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.

    No. Test procedure Test object How to achieve compliance with the requirement
    2.1.1a Functionality of the content is operable through a keyboard

    All types of content and functionality on the website. A visual focus indicator during keyboard navigation is a prerequisite for the test

    All content and functionality on the web page can be accessed and used with a keyboard. Content and/or functionality that it is not appropriate to use with a keyboard is excepted

    Success criterion 2.1.2 No keyboard trap

    Purpose of 2.1.2

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

    Use situations for 2.1.2

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

    • limited vision or without vision
    • limited manipulation or strength

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

    Test procedures, content types and requirements for compliance with 2.1.2

    Test procedure for success criterion 2.1.2:

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

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

    No. Test procedure Test object How to achieve compliance with the requirement
    2.1.2a There are no keyboard traps on the web page

    Components and elements on the web page that it is possible to navigate using a keyboard

    It is possible to navigate through all content on the web page with a keyboard without becoming trapped in any component

    Success criterion 2.2.1 Timing adjustable

    Purpose of 2.2.1

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

    Use situations for 2.2.1

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

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

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

    Interpretation and specification of 2.2.1

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

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

    Test procedures, content types and requirements for compliance with 2.2.1

    Test procedure for success criterion 2.2.1:

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

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

    No. Test procedure Test object How to achieve compliance with the requirement
    2.2.1a It is possible to turn off, adjust or extend time limits

    Web pages that include time limits

    The requirement can be met in several different ways.For web pages that include time limits, one of the following requirements is met:

    It is possible to disable the time limit.

    It is possible to adjust the time limit to at least 10 times the standard duration. The mechanism for adjustment must come before the content that includes time limits.

    It is possible to extend the time limit at least 20 seconds before it expires by executing a simple action. It must be possible to extend by at least 10 times the standard duration.

    Success criterion 2.2.2 Pause, stop, hide

    Purpose of 2.2.2

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

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

    Use situations for 2.2.2

    This success criterion is intended to take into account people with

    • cognitive limitation

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

    Interpretation and specification of 2.2.2

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

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

    Test procedures, content types and requirements for compliance with 2.2.2

    Test procedures for success criterion 2.2.2:

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

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

    No. Test procedure Test object How to achieve compliance with the requirement
    2.2.2a It is possible to pause, stop or hide content that moves, blinks or scrolls

    Web pages with content that moves, blinks or scrolls (that starts automatically and does not stop within five seconds)

    The requirement can be met in several different ways.For web pages with content that moves, blinks or scrolls for more than 5 seconds and that is displayed together with other content and is not a necessary part of an action, one of the following requirements is met:

    There is a mechanism for pausing, stopping or hiding the content. The mechanism is located either directly next to the content or at the start of the page.

    There is a documented keyboard shortcut for pausing, stopping or hiding the content.

    There is a mechanism close to the start of the page for reloading the page without this type of content.

    2.2.2b It is possible to pause, stop, hide or change the update frequency for auto-updating content

    Web pages with autoupdating content that does not move, blink or scroll at the same time (for more than five seconds)

    The requirement can be met in several different ways.For web pages with auto-updating content that is displayed together with other content and is not a necessary part of an action, one of the following requirements is met:

    There is a mechanism for pausing, stopping or hiding the content or controlling the update frequency. The mechanism is located either directly next to the content or at the start of the page.

    There is a documented keyboard shortcut for pausing, stopping or hiding the content or controlling the update frequency.

    Success criterion 2.3.1 Three flashes or below threshold

    Purpose of 2.3.1

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

    Use situations for 2.3.1

    This success criterion is intended to take into account people with

    • seizure disorders

    Interpretation and specification of 2.3.1

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

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

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

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

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

    Test procedures, content types and requirements for compliance with 2.3.1

    Test procedure for success criterion 2.3.1:

    • 2.3.1a The web page has no flashing content.

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

    No. Test procedure Test object How to achieve compliance with the requirement
    2.3.1a The web page has no flashing content

    Web pages with content that blinks (all content, including animations, video clips and images)

    The requirement can be met in several different ways.

    The web page has no content that flashes

    If the web page has content that blinks, one of the following requirements is met:

    1. The content that flashes is smaller than 21,824 square pixels in size.

    2. There are fewer than three flashes per second.

    Success criterion 2.4.1 Bypass blocks

    Purpose of 2.4.1

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

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

    • menus
    • navigation links
    • banner text and advertising frames

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

    Use situations for 2.4.1

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

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

    Interpretation and specification of 2.4.1

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

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

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

    Test procedures, content types and requirements for compliance with 2.4.1

    Test procedure for success criterion 2.4.1:

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

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

    No. Test procedure Test object How to achieve compliance with the requirement
    2.4.1a There is a mechanism for skipping to the primary content on the web page

    Web pages with content that is repeated on multiple pages on the website.

    For web pages with blocks of content that are repeated in multiple locations on the website and that come before the primary content, the following requirements are met:

    There is a mechanism for skipping to the primary content.

    This mechanism is within the first three tab steps, and before the block with content on the web page.

    The mechanism is visible when it receives keyboard focus.

    The mechanism has a descriptive text.

    Visual and functional focus are transferred to the primary content when the mechanism is activated.

    Success criterion 2.4.2 Page titled

    Purpose of 2.4.2

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

    Use situations for 2.4.2

    The success criterion takes into account people with

    • limited vision
    • cognitive limitation

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

    Interpretation and specification of 2.4.2

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

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

    Test procedures, content types and requirements for compliance with 2.4.2

    Test procedure for success criterion 2.4.2:

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

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

    No. Test procedure Test object How to achieve compliance with the requirement
    2.4.2a The web page has a descriptive page title

    Page title on individual web pages

    The page title is coded correctly

    The page title provides a relevant description of the subject or purpose of the page, even when it is read out of context

    Success criterion 2.4.3 Focus order

    Purpose of 2.4.3

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

    Use situations for 2.4.3

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

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

    Interpretation and specification of 2.4.3

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

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

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

    Test procedures, content types and requirements for compliance with 2.4.3

    Test procedure for success criterion 2.4.3:

    • 2.4.3a Keyboard focus order preserves meaning and operability.

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

    No. Test procedure Test object How to achieve compliance with the requirement
    2.4.3a Keyboard focus order preserves meaning and operability

    Web pages that can be navigated sequentially, and where navigation order affects the meaning of the content or operation. (Prerequisite: a visual focus indicator and keyboard operable.)

    The requirement can be met in several different ways.For content that receives keyboard focus and must be navigated in a specific order, one of the following requirements is met:

    Keyboard navigation order and visual order are the same.

    Keyboard navigation order and visual order are not the same, but it is possible to understand and use the content.

    Success criterion 2.4.4 Link purpose (in context)

    Purpose of 2.4.4

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

    Use situations for 2.4.4

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

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

    Descriptive link texts also enhance usability for all users.

    Interpretation and specification of 2.4.4

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

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

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

    Test procedures, content types and requirements for compliance with 2.4.4

    Test procedure for success criterion 2.4.4:

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

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

    No. Test procedure Test object How to achieve compliance with the requirement
    2.4.4a The purpose of each link can be determined from the link text alone or the link text together with its context

    Links that contain text

    The requirement can be met in several different ways.Links that contain text meet the requirement if:

    1. the link text alone provides information on the purpose of the link, or

    2. the link text together with programmatically determined context provides information on the purpose of the link

    We provide a discretionary assessment of whether the link text provides information on the link target. We do not require the link target to be written precisely

    Success criterion 2.4.5 Multiple ways

    Purpose of 2.4.5

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

    Use situations for 2.4.5

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

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

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

    Interpretation and specification of 2.4.5

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

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

    Test procedures, content types and requirements for compliance with 2.4.5

    Test procedure for success criterion 2.4.5:

    • 2.4.5a There are multiple ways to navigate.

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

    No. Test procedure Test object How to achieve compliance with the requirement
    2.4.5a There are multiple ways to navigate

    Navigation options for individual web pages within a set of web pages (website)

    There must be at least two ways of navigating to content on web pages (on websites with more than one web page)

    Success criterion 2.4.6 Headings and labels

    Purpose of 2.4.6

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

    Use situations for 2.4.6

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

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

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

    Interpretation and specification of 2.4.6

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

    Success criteria 2.4.6 and 3.3.2 are closely interlinked:

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

    Test procedures, content types and requirements for compliance with 2.4.6

    Test procedures for success criterion 2.4.6:

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

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

    No. Test procedure Test object How to achieve compliance with the requirement
    2.4.6a Headings describe the content

    Visual headings

    If headings are used, they must describe the subject or purpose of the content to which they belong

    2.4.6b Form elements have descriptive labels

    Labels in forms (all visible text or other components with text in the form)

    Labels describe the subject or purpose of the form element

    Success criterion 2.4.7 Focus visible

    Purpose of 2.4.7

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

    Use situations for 2.4.7

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

    • limited vision
    • cognitive limitation
    • limited manipulation or strength

    Interpretation and specification of 2.4.7

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

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

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

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

    Test procedures, content types and requirements for compliance with 2.4.7

    Test procedure for success criterion 2.4.7:

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

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

    No. Test procedure Test object How to achieve compliance with the requirement
    2.4.7a Keyboard operable content has a visual focus indicator

    Keyboard operable content

    All keyboard operable elements have a visual focus indicator. This does not apply if there is only one component that can be operated using a keyboard on a web page

    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.

    No. Test procedure Test object How to achieve compliance with the requirement
    3.1.1a The default language of the web page is coded correctly

    Text content on web pages

    Web page has a valid language code in the HTML code

    The language code corresponds to the default language of the web page

    Success criterion 3.1.2 Language of parts

    Purpose of 3.1.2

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

    Use situations for 3.1.2

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

    • limited vision or without vision
    • cognitive limitation

    Interpretation and specification of 3.1.2

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

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

    Test procedures, content types and requirements for compliance with 3.1.2

    Test procedure for success criterion 3.1.2:

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

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

    No. Test procedure Test object How to achieve compliance with the requirement
    3.1.2a Content in a language other than the default language is coded correctly

    Text content on web pages that is written in a language that is different to the default language for the page

    For sentences or sections written in a language that is different to the default language for the web page, the following applies:

    The component containing the sentence or section has a valid language code in the HTML code.

    The language code corresponds to the language in which the sentence or section is written.

    Success criterion 3.2.1 On focus

    Purpose of 3.2.1

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

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

    Use situations for 3.2.1

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

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

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

    Interpretation and specification of 3.2.1

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

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

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

    Test procedures, content types and requirements for compliance with 3.2.1

    Test procedure for success criterion 3.2.1:

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

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

    No. Test procedure Test object How to achieve compliance with the requirement
    3.2.1a Keyboard focus does not cause a change of context

    Web pages with components that can receive focus. (Prerequisite: keyboard navigation is possible)

    It is possible to navigate through the web page without a context change taking place when the various components receive focus

    Success criterion 3.2.2 On input

    Purpose of 3.2.2

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

    Use situations for 3.2.2

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

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

    Predictable navigation also enhances usability for all.

    Interpretation and specification of 3.2.2

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

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

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

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

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

    Test procedures, content types and requirements for compliance with 3.2.2

    Test procedure for success criterion 3.2.2:

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

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

    No. Test procedure Test object How to achieve compliance with the requirement
    3.2.2a Changing a setting in a form element does not cause a change of context

    User interface components where the user changes settings. (Prerequisite: keyboard navigation is possible)

    The requirement can be met in several different ways.

    Changing settings in user interface components does not give automatic context changes

    If changing settings in user interface components gives automatic context changes, the user must be notified in advance

    Success criterion 3.2.3 Consistent navigation

    Purpose of 3.2.3

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

    Use situations for 3.2.3

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

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

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

    Interpretation and specification of 3.2.3

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

    Test procedures, content types and requirements for compliance with 3.2.3

    Test procedure for success criterion 3.2.3:

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

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

    No. Test procedure Test object How to achieve compliance with the requirement
    3.2.3a Navigation elements in blocks are repeated in consistent order

    Navigation mechanisms in blocks that are repeated on multiple web pages

    Blocks with navigation mechanisms that are repeated on multiple pages on the website appear in the same relative order on all the pages on which they are present

    Success criterion 3.2.4 Consistent identification

    Purpose of 3.2.4

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

    Use situations for 3.2.4

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

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

    Consistent identification will also be user-friendly for everyone.

    Interpretation and specification of 3.2.4

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

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

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

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

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

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

    Test procedures, content types and requirements for compliance with 3.2.4

    Test procedure for success criterion 3.2.4:

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

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

    No. Test procedure Test object How to achieve compliance with the requirement
    3.2.4a The search function has consistent visual appearance and identification in the code

    Websites with a search function that is available on multiple pages

    In the case of websites with a search function that is available on multiple pages, the search function has consistent visual appearance and identification in the code on all web pages

    Success criterion 3.3.1 Error identification

    Purpose of 3.3.1

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

    Use situations for 3.3.1

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

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

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

    Interpretation and specification of 3.3.1

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

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

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

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

    Test procedures, content types and requirements for compliance with 3.3.1

    Test procedures for success criterion 3.3.1:

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

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

    No. Test procedure Test object How to achieve compliance with the requirement
    3.3.1a Form provides error messages if empty mandatory form fields are detected automatically

    Mandatory form elements

    If it is detected automatically that mandatory form elements have not been filled in, the following applies:

    The user receives an error message in text.

    The error message is coded as text.

    The error message identifies the form element where the error occurred.

    The error message describes the error.

    3.3.1b Form provides error messages if input errors are detected automatically

    Form elements where input data errors are detected automatically

    For all form elements where input data errors are detected automatically, the following requirements are met:

    The user receives an error message in text.

    The error message is coded as text.

    The error message identifies the form element where the error occurred.

    The error message describes the error.

    With the exception of form elements with sensitive content, the information entered remains in the form element.

    Success criterion 3.3.2 Labels or instructions

    Purpose of 3.3.2

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

    Use situations for 3.3.2

    This success criterion is intended to take into account people with

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

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

    Interpretation and specification of 3.3.2

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

    Success criteria 2.4.6 and 3.3.2 are closely interlinked:

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

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

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

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

    Test procedures, content types and requirements for compliance with 3.3.2

    Test procedure for success criterion 3.3.2:

    • 3.3.2a Form elements have instructions or labels.

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

    No. Test procedure Test object How to achieve compliance with the requirement
    3.3.2a Form elements have instructions or labels

    All components in digital forms, including a global search function

    All form elements have labels or instructions that enable the user to use the form

    The following requirements must be met:

    The form element has a visual identification in the form of a label, instruction or icon, symbol or image.

    The identification is visually positioned in or directly next to the form element.

    The identification is always visible when the form element is in focus.

    The icon, symbol or image is identified in the code.

    Information is provided if the form element is mandatory, and any marking with a symbol is explained before it is used.

    Success criterion 3.3.3 Error suggestion

    Purpose of 3.3.3

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

    Use situations for 3.3.3

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

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

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

    Interpretation and specification of 3.3.3

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

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

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

    The requirement does not apply if

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

    Test procedures, content types and requirements for compliance with 3.3.3

    Test procedure for success criterion 3.3.3:

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

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

    No. Test procedure Test object How to achieve compliance with the requirement
    3.3.3a Form provides suggestions for correction if input errors are detected automatically

    Form elements where input data errors are detected automatically

    For all form elements where input data errors are detected automatically, the user receives a suggestion that provides sufficient information on how the error can be corrected

    Success criterion 3.3.4 Error prevention

    Purpose of 3.3.4

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

    Use situations for 3.3.4

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

    Interpretation and specification of 3.3.4

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

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

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

    Test procedures, content types and requirements for compliance with 3.3.4

    Test procedures for success criterion 3.3.4:

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

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

    No. Test procedure Test object How to achieve compliance with the requirement
    3.3.4a In forms that cause commitments or transactions, the user can check and edit information, or undo submission

    Forms that involve legal and/or financial obligations for the user

    Forms that edit or delete userdefined data in data storage systems

    Forms that send responses to tests completed by the user

    The requirement can be met in several different ways:It must be possible to

    either review and edit before submission, or

    undo submission of forms that could result in serious consequences

    One of the following requirements must be met:1. Before submission, the user receives

    a request to review the information entered

    the opportunity to edit all information prior to submission

    a request to confirm that the information is correct

    2. After submission,

    the user receives notification of how they can undo form submission and

    that undoing submission is possible

    3.3.4b The user can confirm or undo deletion of saved information

    Forms that delete userdefined data in data storage systems

    The requirement can be met in several different ways:It must be possible to

    either confirm deletion, or

    undo after deletion of saved information from a form that could result in serious consequences

    One of the following requirements must be met:

    1. Before deletion, the user is asked to confirm that they want to delete the information.

    2. After submission, it is possible to undo the deletion.

    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.

    No. Test procedure Test object How to achieve compliance with the requirement
    4.1.1a The code does not contain syntax errors

    Content coded in HTML or XHTML

    The web page does not have a “Fatal Error” on validation and does not include syntax errors of the following types:

    Elements with incomplete start and end tags.

    Elements that are not nested in compliance with the specifications.

    Elements that contain duplicate attributes.

    Elements that have non-unique IDs.

    Success criterion 4.1.2 Name, role, value

    Purpose of 4.1.2

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

    Use situations for 4.1.2

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

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

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

    Assistive technologies must be able to

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

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

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

    Test procedures, content types and requirements for compliance with 4.1.2

    Test procedures for success criterion 4.1.2:

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

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

    No. Test procedure Test object How to achieve compliance with the requirement
    4.1.2a Form elements are identified in the code

    Form elements such as checkboxes, radio buttons, text fields or drop-down lists

    Form elements are linked to a label in the code. There are several ways of doing this. The label identifies the form element

    If the form element belongs to a group, it is also linked to a label that applies to the group. The label identifies the group

    4.1.2b Buttons are identified in the code

    Buttons for enabling a function or submitting a form, for example

    Buttons that comprise images, coded as links, div, span, etc.

    Buttons are linked to a label in the code. There are several ways of doing this. The label identifies the function of the button

    Buttons that are not coded with standard components in (X)HTML must have information about their roles

    4.1.2c Iframes are identified in the code

    Iframe elements

    If an iframe element is used in the code, the iframe element has a label that identifies the content

    5.5 Key indicators for area surveillance

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

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

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

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

    No. Success criterion Indicator
    1 1.1.1

    Image has a text alternative

    The purpose of a linked image is explained by a link text and/or text alternative

    2 1.2.2

    Prerecorded video with sound has captions

    3 1.3.1

    Headings are coded correctly

    Tables and header cells are coded correctly

    Lists are coded correctly

    4 1.4.1

    Links are distinguishable from other text by means other than colour alone

    5 1.4.2

    It is possible to control sound that starts automatically and does not stop within 3 seconds

    6 1.4.3

    There is sufficient contrast between text and its background

    7 1.4.4

    Text can be enlarged to at least 200 % without loss of content or functionality

    8 2.1.1

    Content and functionality is operable through a keyboard

    9 2.1.2

    There are no keyboard traps on the web page

    10 2.4.4

    The purpose of the links is conveyed by the link text, or the link text together with the context

    11 2.4.6

    Headings describe the content

    12 2.4.7

    Content that is keyboard operable has a visual focus indicator

    13 3.3.1

    Form returns an error message when empty obligatory form fields are automatically detected

    14 3.3.2

    Form elements have instructions or labels

    15 4.1.1

    The code does not contain syntax errors

    16 4.1.2

    Form elements are identified in the code

    Buttons are identified in the code

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

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

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

    6. Appendix: Categorisation of success criteria and test procedures

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

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

    The categorisation is presented in the tables below.

    Topic and test object

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

    No. Test procedure Category or topic Test object
    1 1.1.1a Image has a text alternative Alternative format Images and illustrations
    2 1.1.1b The purpose of a linked image is explained by a link text and/or text alternative Alternative format Images and illustrations
    3 1.1.1c The purpose of selectable regions in image maps is explained by a text alternative Alternative format Images and illustrations
    4 1.1.1d CAPTCHA has a text alternative and an alternative form Alternative format CAPTCHA
    5 1.2.1a Prerecorded audio-only content has a text alternative Alternative format Media content
    6 1.2.1b Prerecorded video-only has a text alternative or audio alternative Alternative format Media content
    7 1.2.2a Prerecorded video with audio has captions Alternative format Media content
    8 1.3.1a Headings are coded correctly Code Headings
    9 1.3.1b Tables and header cells are coded correctly Code Tables
    10 1.3.1c Lists are coded correctly Code Lists
    11 1.3.2a Meaningful reading order is programmatically determined Navigation Web page (content unspecified)
    12 1.3.3a Instructions for use of forms are not solely dependent on sensory characteristics Use of forms Forms
    13 1.4.1a Links are distinguishable from other text by means other than colour alone Navigation Links
    14 1.4.1b Information in graphic representations is distinguishable by means other than colour alone Navigation Images and illustrations
    15 1.4.1c Form elements and error messages are marked by means other than colour alone Use of forms Forms
    16 1.4.2a Control of audio that starts automatically and does not stop within 3 seconds Navigation Media content
    17 1.4.3a There is sufficient contrast between text and its background Navigation Text
    18 1.4.3b There is sufficient contrast between text and its background in an image of text Navigation Images and illustrations
    19 1.4.3c There is sufficient contrast between text and its background (automated test) Navigation Text
    20 1.4.4a Text can be enlarged to at least 200% view with no loss of content or functionality Navigation Text
    21 1.4.5a Image of text is not used unnecessarily Navigation Images and illustrations
    22 2.1.1a Functionality of the content is operable through a keyboard Keyboard operation All user interface components
    23 2.1.2a There are no keyboard traps on the web page Keyboard operation All user interface components
    24 2.2.1a It is possible to turn off, adjust or extend time limits Navigation Time limits
    25 2.2.2a It is possible to pause, stop or hide content that moves, blinks or scrolls Navigation Content that blinks and/or auto-updates
    26 2.2.2b It is possible to pause, stop, hide or change the update frequency for autoupdating content Navigation Content that blinks and/or auto-updates
    27 2.3.1a The web page has no flashing content Navigation Content that blinks and/or auto-updates
    28 2.4.1a There is a mechanism for skipping to the primary content on the web page Keyboard operation Navigation mechanisms
    29 2.4.2a The web page has a descriptive page title Navigation Page title
    30 2.4.3a Keyboard focus order preserves meaning and operability Keyboard operation Web page (content unspecified)
    31 2.4.4a The purpose of each link can be determined from the link text alone or the link text together with its context Navigation Links
    32 2.4.5a There are multiple ways to navigate Navigation Navigation mechanisms
    33 2.4.6a Headings describe the content Navigation Headings
    34 2.4.6b Form elements have descriptive labels Use of forms Forms
    35 2.4.7a Keyboard operable content has a visual focus indicator Keyboard operation All user interface components
    36 3.1.1a The default language of the web page is coded correctly Code Web page (content unspecified)
    37 3.1.2a Content in a language other than the default language is coded correctly Code Web page (content unspecified)
    38 3.2.1a Keyboard focus does not cause a change of context Keyboard operation Web page (content unspecified)
    39 3.2.2a Changing a setting in a form element does not cause a change of context Keyboard operation Forms
    40 3.2.3a Navigation elements in blocks are repeated in consistent order Navigation Navigation mechanisms
    41 3.2.4a The search function has consistent visual appearance and identification in the code Navigation Navigation mechanisms
    42 3.3.1a Form provides error messages if empty mandatory form fields are detected automatically Use of forms Forms
    43 3.3.1b Form provides error messages if input errors are detected automatically Use of forms Forms
    44 3.3.2a Form elements have instructions or labels Use of forms Forms
    45 3.3.3a Form provides suggestions for correction if input errors are detected automatically Use of forms Forms
    46 3.3.4a In forms that cause commitments or transactions, the user can check and edit information, or undo submission Use of forms Forms
    47 3.3.4b The user can confirm or undo deletion of saved information Use of forms Forms
    48 4.1.1a The code does not contain syntax errors Code Source code
    49 4.1.2a Form elements are identified in the code Code Forms
    50 4.1.2b Buttons are identified in the code Code Forms
    51 4.1.2c Iframes are identified in the code Code Iframe

    Use situations

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

    Success criterion Without vision Limited vision Limited perception of colour Deafblindness Without hearing Limited hearing Cognitive limitation Limited manipulation or strength Seizure disorder All users
    1.1.1 Non-text content Yes Yes Yes Yes Yes Yes Yes
    1.2.1 Audioonly and video-only (pre-recorded) Yes Yes Yes Yes Yes
    1.2.2 Captions (pre-recorded) Yes Yes Yes
    1.3.1 Info and relationships Yes Yes
    1.3.2 Meaningful sequence Yes Yes Yes
    1.3.3 Sensory characteristics Yes Yes Yes
    1.4.1 Use of colour Yes Yes Yes
    1.4.2 Audio control Yes Yes Yes
    1.4.3 Contrast Yes Yes Yes
    1.4.4 Resize text Yes Yes
    1.4.5 Images of text Yes Yes Yes
    2.1.1 Access everything with a keyboard Yes Yes Yes
    2.1.2 No keyboard trap Yes Yes Yes
    2.2.1 Timing adjustable Yes Yes Yes Yes Yes Yes Yes
    2.2.2 Pause, stop, hide Yes Yes
    2.3.1 Three flashes or below threshold Yes
    2.4.1 Bypass blocks Yes Yes Yes Yes Yes
    2.4.2 Page titled Yes Yes Yes Yes
    2.4.3 Focus order Yes Yes Yes Yes Yes
    2.4.4 Link purpose (in context) Yes Yes Yes Yes Yes Yes
    2.4.5 Multiple ways Yes Yes Yes Yes Yes Yes
    2.4.6 Headings and labels Yes Yes Yes Yes Yes Yes
    2.4.7 Focus visible Yes Yes Yes
    3.1.1 Language of the page Yes Yes Yes
    3.1.2 Language of parts Yes Yes Yes
    3.2.1 On focus Yes Yes Yes Yes Yes Yes
    3.2.2 On input Yes Yes Yes Yes Yes Yes
    3.2.3 Consistent navigation Yes Yes Yes Yes Yes
    3.2.4 Consistent identification Yes Yes Yes Yes Yes
    3.3.1 Error identification Yes Yes Yes Yes Yes Yes
    3.3.2 Labels or instructions Yes Yes Yes Yes Yes Yes
    3.3.3 Error suggestion Yes Yes Yes Yes Yes Yes Yes
    3.3.4 Error prevention (legal, financial, data) Yes
    4.1.1 Parsing Yes Yes Yes Yes
    4.1.2 Name, role, value Yes Yes Yes Yes

    7. References