Editors

Design

  • The text colour should have enough contrast with its background. This way, the text is easily readable for all visitors. Text must have a minimum contrast ratio of:

    • 4.5:1 for the text smaller than 24px or 19px bold.
    • 3:1 for the text larger than 24px or 19px bold.

    These contrast requirements also apply to text on images.

    Note: These contrast ratios should not be rounded up. The contrast ratio between the hexadecimal colour codes #777777 (gray) and #FFFFFF (white) is 4.47:1. So this is not enough.

    A contrast checker can be used to calculate a contrast ratio. For example, the contrast checker on the website of WebAIM or the Colour Contrast Analyser (software) of The Paciello Group.

    There are a few exceptions for text contrast such as logos, decorative text, and elements that are inactive.

  • Make sure that components that have the same functionality are named the same throughout the website. This makes it easier for visitors to find the repeating parts. This concerns, for example:

    • texts on buttons;
    • labels of the input field;
    • link texts;
    • alternative texts of icons that have the same functionality.

    By naming components in a consistent way, visitors who use screen readers can find their way faster and more efficiently.

    Example:
    The text on the button next to a search field is ‘search’ on all pages, and not ‘find’ on some pages.

Forms

  • Provide labels for input fields

    Labels are the most important element for an accessible form. Provide labels for all input fields or other form elements such as checkboxes, radio buttons, and comboboxes. A clear label describes exactly what needs to be entered in the field, is visible to all visitors and is located close to the input field.

    The label must be linked in the code to the input field. This way you also make the input field accessible to visitors who use assistive technology. The label is the name of the input field. A label also expands the clickable area from which an input field can be selected. This is useful to visitors with a motor impairment.

    Link labels in the code to an input field

    Labels are placed with the <​label> element. To link a <​label> element to a form element use a for/id link. To do so, give the <​label> element a for attribute and the corresponding form element an id attribute with the same value.

    It looks like this in the code:

    				
    					
    				
    			

    There are also ways to visually hide the labels. In that case, ask yourself carefully why you would want to do that. This way the input field will lose the larger clickable area and it may become less obvious to visitors. However, if the label is visually hidden, make sure that a label is still available for assistive technology. To achieve this, use the aria-label, aria-labelledby or a title attribute, which are not visible.

    It looks like this in the code:

    				
    					
    				
    			

    Note: Placeholder text should not be used as the only way to add a label to an input field.

    Group multiple sections of related input fields

    If a form has multiple sections of related input fields, then a <​fieldset> element is used to group them together. Give the <​fieldset> element a label by placing a <​legend> element inside the <​fieldset> element. Assistive technologies use the <​legend> element as if it were a part of the label of the elements in the <​fieldset>.

    The <​fieldset> element is especially relevant for grouping checkboxes and comboboxes, but can also be used to group other input fields.

    It looks like this in the code:

    				
    					
    				
    			

    Provide instructions for input fields

    Instructions give an extra hint for the input field. The instructions in a form should indicate whether there are required fields and possibly whether there is a required input format.

    Indicate that an input field is required

    You can indicate a mandatory input field in text or, for example, with an asterisk (*). Make sure this tag is placed inside the <​label> element.

    It looks like this in the code:

    				
    					
    				
    			

    If the instructions are not clearly named for each input field, it should be indicated in text before the first input field how the mandatory fields are indicated.

    It looks like this in the code:

    				
    					
    				
    			

    Mark the required fields in the code as well. Preferably use the aria-required attribute.

    				
    					
    				
    			
    Indicate if there is a required input format

    Also for required input formats, such as a postal code or an e-mail address, the instructions must describe what the requirements for the input are. This can be done directly in the <​label> element.

    It looks like this in the code:

    				
    					
    				
    			

    This can also be done with the aria-describedby attribute.

    It looks like this in the code:

    				
    					
    				
    			
  • Forms should have an error check built in. The error check automatically analyses whether a required field has been left empty or whether an input field has been filled in incorrectly. If an error is found, the error message should be displayed in text. This text can be supplemented with other visual clues, such as a different colour or an icon.

    In the text of the error message, state the name of the field that was entered incorrectly and state exactly what the error is. Do not write:

    • This field is required.

    But instead write:

    • The field ‘Phone number’ cannot be empty.

    It can also be indicated in the code which field has been filled in incorrectly. To do this, use the aria-invalid attribute. In addition, the error message in the code should be linked to the corresponding input field. This prevents confusion for visitors using assistive technologies. An error message can be linked in a number of ways such as with an aria-describedby attribute.

    It looks like this in the code:

    				
    					
    				
    			

Images

  • Images that convey information are necessary for the understanding of the text. These images add extra information to the page. They must have a text alternative that accurately describes what is shown in the image. The content of the text alternative depends on the context and may differ per situation for the same image.

    In a CMS, a text alternative can usually be added in the media library.

    It looks like this in the code:

    				
    					
    				
    			

    The text alternative must be a good substitute for an image. When writing the text alternative, always think about the purpose of the image. Keep a text alternative useful and concise.

  • There are cases when instead of text only an image is used as a link. These images are called functional images. These can be images that refer to another page or website, but also images that perform an action on the page.

    These images must have a text alternative that describes the purpose of the link, or describes what happens when the image is clicked. Reading software uses the text alternative as link text. That is why it is more important to describe the purpose of the link, rather than what is in the image.

    If there is also text on a functional image, then both the text on the image and the purpose of the link must be included in the text alternative. As a result, visitors who work with speech recognition can also easily reach the link.

    For example, “Go to Twitter.com” is a better text alternative than “A little white bird on a light blue background” when it comes to an image used as a link to Twitter.com.

    				
    					
    				
    			
  • Images placed on the page for purely decorative purposes should not have a text alternative. For example, these are images that do not convey information and are not necessary for the understanding of the text. These images should be ignored by assistive technologies. Decorative graphics are best placed using CSS.

    				
    					
    				
    			
    				
    					
    				
    			

    If it is not possible to place a decorative image with CSS, then the alt attribute in the <​img> element should be left empty. The alt attribute must be present, but without any text.

    				
    					
    				
    			

    Note: In some cases this can also be done with ARIA role="presentation" of aria-hidden="true".

  • Sometimes it is not possible to fully describe an image in a short text alternative. For example, when it comes to an extensive infographic or a graph. These types of complex images should also be fully described in a text alternative. In that case, in addition to a concise description in the alt attribute, also provide a longer description in the surrounding text.

    				
    					
    				
    			

    A longer description may also be placed on a separate page. In that case, place a link with the reference to that other page immediately before or after the image.

    				
    					
    				
    			

    The surrounding text should also be linked to the image. This is not mandatory, but very useful. It can be done with the aria-describedby attribute. Use the ID of the element where the complex image is described. This information should also be visible to the visitors who are able see.

    				
    					
    				
    			
  • Do not use images of text to convey information. Images of text are not suitable for all the visitors. Often the font size in an image does not scale well. The visitors cannot also adjust the embedded text to their own style preferences.

    Use ‘real’ text. Text that actually appears as text on the page can be styled with CSS. For example, this can be used to adjust the colour, font, font size, line height and letter spacing. It is also possible to place text on an image with CSS.

    There are a few exceptions where an image of text may be used:

    1. It is not possible to achieve the same visual representation with HTML and CSS.
    2. The representation of the text in the image is essential to the information being conveyed.
    3. The image of text can be adjusted to the preferences of the visitor.

  • Do not use flashing content and do not allow for it to flash more than 3 times per second. Visitors with certain forms of epilepsy may experience a seizure when viewing flashing images or media.

Media

  • All media files must have a brief textual introduction, even if full alternatives such as a transcript or audio description are available. Such a short introduction should roughly describe the contents of the media file. With this information, visitors can decide for themselves what they want to do with the media file. This is especially useful to visitors who cannot easily scan the content, such as visitors who use screen readers.

    A short textual introduction can be given with a descriptive headline, a descriptive title or possibly a descriptive label.

  • All sound clips and moving images must have a transcript. A transcript can also be a valuable addition to videos. A transcript is a written text describing everything that can be seen, heard and done. For example, all spoken text, but also the important images and sounds. Any interactive elements, such as a link, should also be included in a transcript.

    A good transcript:

    • contains all spoken text.
    • describes all important images.
    • describes all the important sounds.
    • contains all links.
    • describes who speaks when it is important.
    • emphasizes the speaker’s volume when it is important.

    A transcript should be easily accessible for all visitors. Always place a transcript, or a link to the transcript directly below the code of the media file.

    A transcript must always be added to sound clips. For the moving images, a transcript should only be added if no audio description is available. For videos, this is only required when there are interactive elements present in the video.

  • All videos must have subtitles for the deaf and the hard of hearing. In subtitles for the deaf and the hard of hearing, the spoken text and important sounds must be included. Important sounds are, for example, a doorbell or an explosion. Music can also be important to understand the video or the atmosphere of the video.

    Good subtitles:

    • contain all spoken text.
    • describe all the important sounds.
    • describe who is speaking if this is not immediately clear.
    • emphasize the speaker’s volume if it is important.
    • are clearly visible.
    • match the sound as much as possible.
    • do not cover any other information.

    The spoken text may be simplified to keep the subtitles from being too long.

    There are several ways to add subtitles: embedded in the video (open captions) or added as a separate subtitle file to the video (closed captions).

    How to add subtitles on the major video platforms:

  • Not all information available in videos is conveyed with sound. Some things can be seen but cannot be heard. This visual information must be added to the video with an audio description. In an audio description, a voice-over describes important visible images that cannot be deduced from what can be heard in the video. This can, for example, include actions, persons, but also text that can only be seen in the image. This takes place when there are pauses in the original sound of the video. This way visitors who are blind or visually impaired can also follow the video well.

    There are several ways to add an audio description: added in the sound of the movie or added as an alternative audio track.

    Note: An extra audio track is not (yet) supported by the major video platforms.

    An audio description should be synchronized as much as possible with the visible information.

    An audio description is not always necessary for videos. If all visible information can also be heard, then it is not mandatory. An audio description should only be added to moving images if no transcript is available.

  • Do not use flashing content and do not allow for it to flash more than 3 times per second. Visitors with certain forms of epilepsy may experience a seizure when viewing flashing images or media.

Navigation

  • The page title should describe the topic or purpose of the page. A descriptive page title makes it easier for everyone to navigate the website. Page titles are displayed in the browser window or in a tab. A good page title helps visitors to easily find the page when, for example, several tabs are open in the browser.

    Good page titles:

    • clearly describe the topic or purpose of the page.
    • change when a new page is loaded.
    • have the unique information in front.
    • are uniform with the other pages.
    • are concise.
    • are unique.

    Page titles are used by the assistive technology to identify the web page. This is the first information that is presented when a page is opened.

    Use the title element in the <​head> element in the page’s code. In this element, describe the topic or purpose of the page.

    It looks like this in the code:

    				
    					
    				
    			

    In a CMS, the page title can often be set per page of the website.

  • Give links on a web page a link text from which the purpose of the link can be easily understood. A descriptive link text is clear to everyone. Make sure that the link text is formulated in such a way that the visitors immediately know what the link refers to.

    Do not write:

    • Read more. (unclear)
    • LinkedIn. (unclear)

    But write:

    • Read more about digital accessibility.
    • Go to our LinkedIn page.

    Tip: If you reference an e-mail address, use the full e-mail address as the link text.

    Visitors using a screen reader can use a list of all links to navigate the page.

    If there really is no other option, then the context of the link may also be used to describe the purpose of the link. For example, the same sentence, paragraph, or in the same table cell. The link text can also be extended in the code with the aria- label attribute or with the title attribute.

    It looks like this in the code:

    				
    					
    				
    			

    Wat ook kan is het verbergen van een deel van de linktekst met CSS:

    				
    					
    				
    			
    				
    					
    				
    			

    Note: Link texts that are expanded using CSS or the aria-label attribute are only visible to visitors using a screen reader.

    A link text should never be left empty. Without a link text it is impossible to determine where the link refers to. An empty link may not be visible on the page, but these links will appear in the focus order. Screen readers will notice these links as well.

    In cases where not only text but also an image is used as a link, we speak of functional images. Give images that are also a link a text alternative that describes what the link points to. If an image and a text are used with both the same link purpose, it is better to combine them into one link. For visitors who use assistive technologies, it can be distracting if the same link is read twice in a row.

Text

  • The page title should describe the topic or purpose of the page. A descriptive page title makes it easier for everyone to navigate the website. Page titles are displayed in the browser window or in a tab. A good page title helps visitors to easily find the page when, for example, several tabs are open in the browser.

    Good page titles:

    • clearly describe the topic or purpose of the page.
    • change when a new page is loaded.
    • have the unique information in front.
    • are uniform with the other pages.
    • are concise.
    • are unique.

    Page titles are used by the assistive technology to identify the web page. This is the first information that is presented when a page is opened.

    Use the title element in the <​head> element in the page’s code. In this element, describe the topic or purpose of the page.

    It looks like this in the code:

    				
    					
    				
    			

    In a CMS, the page title can often be set per page of the website.

  • The headings on a web page should describe the topic or purpose of the underlying text. Make sure each heading says something about the text below it. A descriptive heading makes it easier for anyone to find information on a page. All headings together should give a good idea of the content of the web page. This allows visitors to quickly recognize the structure of a web page or text.

    A heading must always have an underlying content.

    Visitors using a screen reader can use a list of all headings to navigate over the web page. They can also jump straight to the next heading.

  • Thanks to well-written descriptive headings, visitors can quickly recognize the structure of a text. A heading often has a different design, for example it is larger and in bold. It makes it easier to scan the structure of the page.

    The structure that is only conveyed through design cannot be perceived (or not properly perceived) by visitors who are blind or partially sighted. For these visitors it is important to also record structure in the code. For example, software can also determine the structure and the relationships on the web page.

    Visitors using a screen reader can use a list of all headings to navigate the page. They can also jump straight to the next heading.

    Make sure that all headings are formatted with an HTML element (h1 to h6).

    Note: Texts that are not headings may not be formatted with an HTML heading element.

    Further make sure that the order of the headings and subheadings is logical. A few rules apply:

    • The first heading on the page should be a first-level heading.
    • A first-level heading should be followed by a second-level heading.
    • A second-level heading should be followed by another second-level heading or a third-level heading.
    • The heading levels should not be skipped.
    				
    					
    				
    			

    In a CMS, a text can be selected and indicated that it is a heading. You can also choose the level of a heading. This automatically formats the text with the correct HTML element.

  • Lists emphasize important points in a text. A list often has a different design. Parts of a list are formatted with a bullet or a number.

    Structure that is only conveyed through design cannot be perceived (or not properly perceived) by visitors who are blind or partially sighted. For these visitors it is important to also record structure in the code. For example, software can also determine the structure and the relationships on the web page.

    Visitors who use a screen reader can navigate through a list more easily. For example, screen readers indicate how many items are in the list and offer the option to skip the list completely.

    Make sure lists are formatted with a list element. There are different types of lists: a bulleted list (<​ul>), a numbered list (<​ol>), and a descriptive list (<​dl>).

    Bulleted list

    Items in a bulleted list are preceded by a bullet character such as a bullet or dash. Use bullet points when the order of the items in the list is not important.

    It looks like this in the code:

    				
    					
    				
    			

    Numbered list

    Items in a numbered list are preceded by a number. Use numbered lists when the order of the items on the list is important.

    It looks like this in the code:

    				
    					
    				
    			

    Description list

    Use a description list for lists that consist of a name, a term, or a concept with a description that goes with it. For example, it can be used for a glossary of terms. In a description list, the <dt> element is used to indicate a term and the <dd> element is used to indicate the description.

    It looks like this in the code:

    				
    					
    				
    			

    In a CMS, you can select a text and mark it as a list. You can choose between a bulleted or a numbered list. This automatically formats the text with the correct HTML element.

    Note: A description list is not always supported.

  • Tables consist of rows and columns. The data in those rows and columns is interrelated. For visitors with a visual impairment, this relationship is not immediately clear. For these visitors it is important that these relationships are also registered in the code.

    Structure and relationships that are only conveyed through design, cannot be (properly) perceived by visitors who are blind or visually impaired. For these visitors it is important to also register the structure in the code. For example, software can also determine the structure and relationships on the web page.

    Bezoekers die gebruik maken van een schermlezer kunnen makkelijker door een lijst navigeren. Schermlezers geven bijvoorbeeld aan hoeveel onderdelen er in de lijst staan en bieden de mogelijkheid om de lijst gelijk over te slaan.

    Make sure that tables are formatted with a table element (<​table>). This element must also specify what a table headers are and what the data cells are. The table headers are coded with a <​th> element, and the data cells with a <​td> element.

    It looks like this in the code:

    				
    					
    				
    			

    Also give the table a short description. This description is coded with a <caption> element. A good description helps visitors find a table and understand what the table is about.

    It looks like this in the code:

    				
    					
    				
    			

    A table can (in many cases) be inserted in a CMS. Determine the number of rows and columns, and precisely indicate what the table headers are. This automatically formats the table with the correct HTML elements.

  • Give links on a web page a link text from which the purpose of the link can be easily understood. A descriptive link text is clear to everyone. Make sure that the link text is formulated in such a way that the visitors immediately know what the link refers to.

    Do not write:

    • Read more. (unclear)
    • LinkedIn. (unclear)

    But write:

    • Read more about digital accessibility.
    • Go to our LinkedIn page.

    Tip: If you reference an e-mail address, use the full e-mail address as the link text.

    Visitors using a screen reader can use a list of all links to navigate the page.

    If there really is no other option, then the context of the link may also be used to describe the purpose of the link. For example, the same sentence, paragraph, or in the same table cell. The link text can also be extended in the code with the aria- label attribute or with the title attribute.

    It looks like this in the code:

    				
    					
    				
    			

    Wat ook kan is het verbergen van een deel van de linktekst met CSS:

    				
    					
    				
    			
    				
    					
    				
    			

    Note: Link texts that are expanded using CSS or the aria-label attribute are only visible to visitors using a screen reader.

    A link text should never be left empty. Without a link text it is impossible to determine where the link refers to. An empty link may not be visible on the page, but these links will appear in the focus order. Screen readers will notice these links as well.

    In cases where not only text but also an image is used as a link, we speak of functional images. Give images that are also a link a text alternative that describes what the link points to. If an image and a text are used with both the same link purpose, it is better to combine them into one link. For visitors who use assistive technologies, it can be distracting if the same link is read twice in a row.

  • In instructions, do not refer only to sensory properties of components such as shape, color, size, location, orientation, or sound, but also use text.

    Do not write:

    • Use the round button to send your data. (form)
    • We are available on the days marked with a green dot. (colour)
    • Click the button at the bottom right of the page to go to the next page. (location)

    Instead write:

    • Use the (round, green) button (at the bottom) with the text “Send” to submit your details.

    Instructions in which only sensory properties are used cannot be properly followed by all visitors. For example, visitors who are blind or visually impaired cannot perceive shape, size or location. Instructions in which only sound is used cannot be (properly) followed by visitors who are deaf or hard of hearing.

  • Specify the default language of a web page in the code. For example, software can determine the language of the web page. If there are several languages on a page, use the language that is most common.

    Reading software reads a web page. The pronunciation of the words depends on the language of the page. If no language or a wrong one is specified in the code, reading software may read the content incorrectly or unclearly. The default language of the browser is then used and it does not always match the language of the content.

    Add the lang attribute to the html element to set the language of a web page. Use the correct language code in this attribute. A language code consists of a two letters.

    It looks like this in the code:

    				
    					
    				
    			

    Each language has its own designation. For Dutch it is ‘nl’ (lang=”nl”), for English it is ‘en’ (lang=”en”), for German it is ‘de’ (lang=”de”). View all language codes on IANA Language Subtag Registry.

    In a CMS, the language of a website can be specified in the settings.

  • If a sentence or paragraph in the content is written in a language other than the default language, this must be indicated in the code. This way software can determine the language of the web page. This obligation only applies to sentences and paragraphs, not to individual words.

    Reading software reads a web page. The pronunciation of the words depends on the language of the page. If no language or a wrong one is specified in the code, reading software may read the content incorrectly or unclearly. The default language of the browser is then used and it does not always match the language of the content.

    Add the lang attribute to the elements with a different language. Give this attribute a value that consists of a two-letter code that represents a language. The lang attribute can be used at the block level (<​div>, <​p>, <​table>, etc.) but also on inline elements (<​span>, <​a>, <​strong>, etc.).

    It looks like this in the code:

    				
    					
    				
    			

    There are exceptions for proper nouns, technical terms, words of an indefinite language, and words or phrases that have become part of the vernacular of the surrounding text.

    View all language codes on IANA Language Subtag Registry.

    Note: Not all kids of CMS support this feature.

Succescriteria

  • Principle 1. Perceivable
    • Guideline 1.1 Text Alternatives
      • 1.1.1 Non-text Content
    • Guideline 1.2 Time-based Media
      • 1.2.1 Audio-only and Video-only (Prerecorded)
      • 1.2.2 Captions (Prerecorded)
      • 1.2.3 Audio Description or Media Alternative (Prerecorded)
      • 1.2.4 Captions (Live)
      • 1.2.5 Audio Description (Prerecorded)
    • Guideline 1.3 Adaptable
      • 1.3.1 Info and Relationships
      • 1.3.3 Sensory Characteristics
    • Guideline 1.4 Distinguishable
      • 1.4.3 Contrast (minimum)
      • 1.4.5 Images of Text
  • Principle 2. Operable
    • Guideline 2.3 Seizures and Physical Reactions
      • 2.3.1 Three Flashes or Below Threshold
    • Guideline 2.4 Navigable
      • 2.4.2 Page Titled
      • 2.4.4 Link Purpose (In Context)
      • 2.4.6 Headings and Labels
    • Guideline 2.5 Input Modalities
      • 2.5.3 Label in Name
  • Principle 3. Understandable
    • Guideline 3.1 Readable
      • 3.1.1 Language of Page
      • 3.1.2 Language of Parts
    • Guideline 3.2 Predictable
      • 3.2.4 Consistent Identification
    • Guideline 3.3 Input Assistance
      • 3.3.1 Error Identification
      • 3.3.2 Labels or Instructions
  • Principle 4. Robust
    • Guideline 4.1 Compatible
      • 4.1.2 Name, Role, Value