Some are already in place, some are quick fixes, some are long-term, and finally some are for content developers and should be added to the Digitization Guidance.
Rationale
UNICEF wants everyone who visits its websites to feel welcome and to find the experience rewarding. To help make our websites a positive place for everyone, we use the Web Content Accessibility Guidelines (WCAG) 2.0. developed by the World Wide Web Consortium (W3C), in cooperation with individuals and organizations throughout the world, to provide a single shared standard for web content accessibility that meets the needs of individuals, organizations, and governments internationally. The guidelines explain how to make web content more accessible for people with disabilities and more user friendly for everyone.
The guidelines have three levels of accessibility (A, AA, and AAA). UNICEF has chosen Level AA as the target for UNICEF websites. This is in line with international best practice.
These standards, should provide staff with the know-how to create an accessible website or request to request it from vendors in line with the Procedures for Establishing and Managing UNICEF's Public-Facing Websites, Social Media Channels and Mobile Applications.
Guiding principles
Web accessibility refers to the practice of making websites usable by everybody, including those with different disabilities. The effective application of accessible design and development practices should ensure that all users have equal access to our information and site functionality.
As a UN agency, UNICEF is a promoter of web accessibility, embodying the principles of the UN Convention on the Rights of Persons with Disabilities.
Embracing web accessibility also ensures that information or resources we produce that are relevant to disabled children are fully usable by all persons with disabilities.
Colour
Approximately 1 in 12 men and 1 in 200 women experience some sort of colour deficiency. Some cannot distinguish red, green and blue. Others have difficulties distinguishing foreground from background if the contrast is insufficient. Ensuring proper contrast between foreground and background also benefits partially sighted users and anyone using a mobile device in sunny conditions.
Ensure that all information conveyed with colour is also available without colour.
[ ] Avoid statements such as “Press the green button to submit your results.” Ensure that understanding the purpose of the button does not rely on colour alone. Instead, use phrasing such as "Press the button labeled Go to submit your results."
[ ] Use additional visual cues where appropriate. For example, if obligatory fields are colored red, also include an additional indicator such as the word “Required” in the label for the field.
[ ] Use a visual distinction, other than colour, to style links within text (for example, underlining or bold styling).
Ensure that all text contrasts sufficiently with its background when viewed by someone with colour vision deficiency, or when viewed on a black and white screen.
Avoid using red and green or blue and yellow together as foreground and background colours. These combinations will appear as shades of gray to colourblind users, making any text very difficult to read.
Follow these rules from WCAG 2.0 to ensure sufficient contrast between foreground and background:
Use a colour-contrast checker tool (such as: http://colorsafe.co/) to confirm whether your colour combinations meet the above standards.
[ ] The visual presentation of text and images of text should have a contrast ratio of at least 4.5:1.
[ ] Large-scale text and images of large-scale text should have a contrast ratio of at least 3:1.
[ ] Logos and incidental text that are purely decorative, that are not visible to anyone, or that are part of a picture that contains significant other visual content have no contrast requirement.
Forms
Badly designed forms can cause difficulties for people with vision, mobility, or cognitive impairments. Accessible forms need to have a clear relationship between form labels and fields for users who cannot see the form. They must also have a clear, logical order that works via a keyboard for assistive technologies. Clarity, predictability, and division of forms into manageable sections are also important for people with certain cognitive disabilities.
Included in #699
Images
Images are not directly accessible to someone who cannot see. If an image is used to convey meaning, it is therefore important to provide equivalent information in text format that can be used by assistive technologies. In addition, text in bitmap images cannot be easily adapted to suit user preferences in the same way as regular text (for example, color contrast will not be modifiable and font resizing functionality in browsers will not work on it). Important contextual information will also be missing if images are used without considering appropriate semantic markup such as headings and lists.
[ ] Images should have alternative text that conveys their meaning to users of assistive technology who cannot see them on the page. For example: img=“search.gif” alt=“search”
When employing alternative text:
[ ] Ensure that the text presents the same content and function as the image and that the alternative text makes sense within the context the image is used on the page.
[ ] When an image contains words that are important to understanding the content, the alt text should include those words. Such inclusion will allow the alt text to play the same function on the page as the image.
[ ] All linked images must contain descriptive alt text that designates the destination/function of the link.
[ ] Do not use “picture of” or “image of” in the alternative text; it is unnecessary. Similarly, avoid placeholder words or programming references such as “picture1” or “Oct.jpg.”
[ ] Keep alt text reasonably short while still being adequately descriptive.
[ ] In cases where an image is purely decorative, always apply empty alt text (alt=””). Doing so will convey to assistive technology that the image is decorative and that the file name of the image should not be announced. Decorative images can also be added using CSS to avoid the need for alternative text.
[ ] Avoid providing redundant alternative text that is available adjacent to the image. In cases like this, it is better to consider the image as decorative than to present the same text twice.
[ ] Avoid using lengthy descriptions that do not carry any essential information, e.g. describing colors etc.
[ ] For more complicated images like charts, you may need to use the “longdesc” attribute. This provides a link to a longer description of the image (for example, <img src= “chart.gif” alt=“a complex chart” longdesc=“chartdesc.html”>).
[ ] When using imagemaps, ensure that all the elements for each selectable region have descriptive alt text.
[ ] Avoid using images of text unless the particular presentation of the text is essential (for example in logos or charts). If an image containing text needs to be used, then a text alternative should always be provided using “alt” text or longdesc as appropriate.
[ ] Avoid adding text in images via CSS. Images placed with CSS cannot have “alt” text added.
[ ] Be especially careful that images are not used in place of meaningful page elements such as headings or navigational lists, which can help assistive technology users better comprehend pages. Do not use the “meta keywords” field to add keywords to pages.
While following the above principles, remember that providing images to complement text can be a useful aid to enhance comprehension for sighted users. It can also be especially useful for people with dyslexia or learning difficulties. As long as a text alternative is provided, do not ignore the potential for images such as illustrations, charts, and maps to act as communication aids.
Links
Creating links with regard to accessibility is essential for providing a smooth experience for users of assistive technology. Screen readers provide the ability to navigate through the links on a page; link text should therefore be descriptive and short, and should make sense out of context.
Empty link text is also an issue because the presence of the link may still be announced by assistive technology and cause confusion.
Broken links are a general usability issue for all users, but they can be particularly frustrating for users of assistive technology who will need to expend additional effort on identifying an alternative path to the information the broken link should have led to.
[ ] Make link text descriptive of the link destination.
[ ] Do not use short, non-descriptive phrases like “click here,” “more,” or “available online” as the entire link text. Link text should be meaningful enough to make sense when read out of context.
[ ] Don’t make link text longer than necessary to adequately describe the linked-to resource. Shorter links are easier for users of assistive technology to use.
[ ] Indicate when a link is to a non-HTML page (e.g., PDF) and indicate the file format and size. Include the information on file format and size within or directly after the link (e.g., Strategic Plan 2014-2017 (PDF 115Kb)).
[ ] Ensure that you have no “empty” links in the code without visual link text (e.g., ).
[ ] Links with the same text that go to different locations must be readily distinguishable.
[ ] All linked images must have descriptive alt text. (See “Accessibility: Images.”)
[ ] Color alone must not be used to distinguish links from surrounding text. (See "Color.")
[ ] Ensure that there are no broken links on sites.
Navigation
[ ] Navigational mechanisms should always be presented in a uniform, well-structured, and logical order so as to avoid confusion or disorientation. Ensuring that repeated components occur in the same order on each page of a site helps users become comfortable that they will be able to predict where they can find things. This logicality helps users with cognitive limitations, users with low vision, and also those who are blind.
[ ] There should also be multiple ways to locate a particular web page, unless it is part of a process such as a check-out or search function. This multi-functionality makes it possible for users to locate content in a manner that best meets their needs. Users may find one technique easier or more comprehensible to use than another.
[ ] It is also important that navigation be accessible via a keyboard. When content can be operated through a keyboard or alternate keyboard, it is operable by people with no vision (who cannot use devices such as mice that require eye-hand coordination) as well as by people who must use alternate keyboards or input devices that act as keyboard emulators.
A consistent and predictable navigation scheme is a very important aid to website accessibility.
[ ] Ensure that navigation mechanisms repeated on multiple web pages occur in the same relative order each time they are repeated.
For example:
[ ] The search field should always be in the same place on each page.
[ ] “Skip navigation” links should be provided as the first link on every page. This premier positioning allows users to have a consistent way to quickly bypass header information and navigational content so they can begin interacting with the main content of a page.
[ ] “Skip to top” links should be provided at the bottom of each page so that keyboard users can easily jump to the top of the page when required. Ensure that your Content Management System (CMS) creates pages and links that search engines can crawl.
[ ] Ensure that navigation mechanisms are presented consistently across pages.
[ ] For example, the search function should not be labelled “search” on one page and “find” on another.
[ ] Include multiple ways of navigating a site, including at least either a search function or a sitemap as well as navigational links between pages.
[ ] Never use graphical text within your navigation scheme. HTML text should be used instead because it is resizable and easily read out by screen readers.
[ ] Ensure that the website can be navigated without using a mouse. This can be tested by pressing the tab key on your dashboard to see the cursor move through links, form fields, and objects. Keyboard focus should be easily trackable on the page. The selected link or control should be highlighted using a prominent rectangle or change in color with sufficient contrast.
Tables
Tables represent a complicated environment for visually-impaired users. That is because such individuals cannot easily see and understand the table structure. It is therefore necessary to add mark-up that will help screen-reader users navigate tables.
[ ] Using complicated, nested tables for layout may cause content to be rendered in the wrong order by screen readers. CSS should be used for layout instead.
[ ] On UNICEF sites, HTML tables (using the HTML
element) should only be used to display tabular data. They should not be used for design or layout purposes.
When using data tables:
(c) For simple tables:
[ ] Identify row and column headers with the
tag.
(d) For more complex tables:
[ ] Where the header is not in the first row or column, use the “scope” attribute to associate header cells and data cells.
[ ] Where data cells are associated with more than one row and/or column heading, use “id” and “header” attributes to associate header cells and data cells in data tables.
[ ] Do not misuse structural HTML tags to create visual effects within tables. For example, do not use the table header tag to create bold formatting on text that isn’t a heading. Instead use CSS to control visual formatting.
[ ] Captions may usefully be added for screen-reader users. The “caption” element acts like a title or heading for the table. It ensures that the table identifier remains associated with the table, including visually (by default). In addition, using the caption element allows screen reading software to navigate directly to the caption for a table, if one is present.
[ ] Don’t use white space characters (e.g., space, tab, line break, or carriage return) to format text as tables or columns.
[ ] Don’t use the HTML
element to markup tabular information. Instead use the HTML table element.
Titles and headings
Descriptive titles are important indicators of a page’s content and are the first thing a user of a screen reader will hear read aloud to him or her on a page. With headings, sighted users perceive them as a visual cue to the structure of a document – headings are often in a larger, bold font and are separated from paragraphs by blank lines.
Marking up headings appropriately ensures that this structure will be available for users of assistive technology. In a 2014 survey, 66% of screen-reader users said they used headings as shortcuts to navigate through pages, making this the most popular screen-reader navigation technique.
[ ] Always provide a meaningful, concise page title in the
tag. The title should describe the page’s content.
[ ] Ensure you use correct heading markup for headings – e.g.,
,
,
,
. Do not indicate headings using just bold or larger text.
[ ] Include a single
heading on each page for the main page’s heading.
[ ] Make the text of headings informative and avoid having multiple headings with identical text (e.g., “More Details”) unless the structure of the page provides adequate differentiation between them.
[ ] To facilitate navigation and understanding of the overall document structure, use headings that are properly nested (e.g., h1 followed by h2, h2 followed by h2 or h3, h3 followed by h3 or h4, etc.).
Video
Providing a text transcript for all videos and audio files guarantees a basic level of access to the information being communicated because textual content is more easily manipulated by assistive technologies. Transcripts are also useful for SEO, since they give search engines text to index.
Captioning videos with dialogue is an essential service for users with a hearing impairment, but it can also be useful for people whose first language is different from that of the video or for users who need to access the video with the sound off – e.g., in a noisy environment without headphones. It is also essential to consider the keyboard usability of the video or audio player technology you use, since many assistive technologies rely upon the keyboard when viewing the content.
[ ] Supply closed caption files of any dialogue when you upload a pre-recorded video.
[ ] Provide a descriptive text transcript of any video or audio file.
[ ] Provide clear instructions for using video or audio content. Do not create pages with nothing but an embedded video on them. If you do so, people without the appropriate viewing technology will only see an empty page. Provide information on the page about the content of the video (which will also be beneficial for SEO).
[ ] For videos hosted on UNICEF’s websites, never play videos automatically when a page opens. The video audio will run at the same time as the user’s screen reader audio and the user will need to search for the controls on the page to stop the video.
[ ] For videos hosted on UNICEF’s websites, avoid flashing or flickering content. Videos with content that flashes more than three times in a second may trigger migraines or induce seizures in users with photosensitive epilepsy as well as other photosensitive seizure disorders.
In order to fully comply with UNICEF's Web Accessibility Standards (2020/06/17), we need to consider the items below.
Some are already in place, some are quick fixes, some are long-term, and finally some are for content developers and should be added to the Digitization Guidance.
Rationale
UNICEF wants everyone who visits its websites to feel welcome and to find the experience rewarding. To help make our websites a positive place for everyone, we use the Web Content Accessibility Guidelines (WCAG) 2.0. developed by the World Wide Web Consortium (W3C), in cooperation with individuals and organizations throughout the world, to provide a single shared standard for web content accessibility that meets the needs of individuals, organizations, and governments internationally. The guidelines explain how to make web content more accessible for people with disabilities and more user friendly for everyone.
The guidelines have three levels of accessibility (A, AA, and AAA). UNICEF has chosen Level AA as the target for UNICEF websites. This is in line with international best practice.
These standards, should provide staff with the know-how to create an accessible website or request to request it from vendors in line with the Procedures for Establishing and Managing UNICEF's Public-Facing Websites, Social Media Channels and Mobile Applications.
Guiding principles
Web accessibility refers to the practice of making websites usable by everybody, including those with different disabilities. The effective application of accessible design and development practices should ensure that all users have equal access to our information and site functionality. As a UN agency, UNICEF is a promoter of web accessibility, embodying the principles of the UN Convention on the Rights of Persons with Disabilities. Embracing web accessibility also ensures that information or resources we produce that are relevant to disabled children are fully usable by all persons with disabilities.
Colour
Approximately 1 in 12 men and 1 in 200 women experience some sort of colour deficiency. Some cannot distinguish red, green and blue. Others have difficulties distinguishing foreground from background if the contrast is insufficient. Ensuring proper contrast between foreground and background also benefits partially sighted users and anyone using a mobile device in sunny conditions.
Ensure that all information conveyed with colour is also available without colour.
[ ] Avoid statements such as “Press the green button to submit your results.” Ensure that understanding the purpose of the button does not rely on colour alone. Instead, use phrasing such as "Press the button labeled Go to submit your results."
[ ] Use additional visual cues where appropriate. For example, if obligatory fields are colored red, also include an additional indicator such as the word “Required” in the label for the field.
[ ] Use a visual distinction, other than colour, to style links within text (for example, underlining or bold styling).
Ensure that all text contrasts sufficiently with its background when viewed by someone with colour vision deficiency, or when viewed on a black and white screen. Avoid using red and green or blue and yellow together as foreground and background colours. These combinations will appear as shades of gray to colourblind users, making any text very difficult to read.
Follow these rules from WCAG 2.0 to ensure sufficient contrast between foreground and background:
Use a colour-contrast checker tool (such as: http://colorsafe.co/) to confirm whether your colour combinations meet the above standards.
[ ] The visual presentation of text and images of text should have a contrast ratio of at least 4.5:1.
[ ] Large-scale text and images of large-scale text should have a contrast ratio of at least 3:1.
[ ] Logos and incidental text that are purely decorative, that are not visible to anyone, or that are part of a picture that contains significant other visual content have no contrast requirement.
Forms
Badly designed forms can cause difficulties for people with vision, mobility, or cognitive impairments. Accessible forms need to have a clear relationship between form labels and fields for users who cannot see the form. They must also have a clear, logical order that works via a keyboard for assistive technologies. Clarity, predictability, and division of forms into manageable sections are also important for people with certain cognitive disabilities.
Included in #699
Images
Images are not directly accessible to someone who cannot see. If an image is used to convey meaning, it is therefore important to provide equivalent information in text format that can be used by assistive technologies. In addition, text in bitmap images cannot be easily adapted to suit user preferences in the same way as regular text (for example, color contrast will not be modifiable and font resizing functionality in browsers will not work on it). Important contextual information will also be missing if images are used without considering appropriate semantic markup such as headings and lists.
When employing alternative text:
[ ] Ensure that the text presents the same content and function as the image and that the alternative text makes sense within the context the image is used on the page.
[ ] When an image contains words that are important to understanding the content, the alt text should include those words. Such inclusion will allow the alt text to play the same function on the page as the image.
[ ] All linked images must contain descriptive alt text that designates the destination/function of the link.
[ ] Do not use “picture of” or “image of” in the alternative text; it is unnecessary. Similarly, avoid placeholder words or programming references such as “picture1” or “Oct.jpg.”
[ ] Keep alt text reasonably short while still being adequately descriptive.
[ ] In cases where an image is purely decorative, always apply empty alt text (alt=””). Doing so will convey to assistive technology that the image is decorative and that the file name of the image should not be announced. Decorative images can also be added using CSS to avoid the need for alternative text.
[ ] Avoid providing redundant alternative text that is available adjacent to the image. In cases like this, it is better to consider the image as decorative than to present the same text twice.
[ ] Avoid using lengthy descriptions that do not carry any essential information, e.g. describing colors etc.
[ ] For more complicated images like charts, you may need to use the “longdesc” attribute. This provides a link to a longer description of the image (for example, <img src= “chart.gif” alt=“a complex chart” longdesc=“chartdesc.html”>).
[ ] When using imagemaps, ensure that all the elements for each selectable region have descriptive alt text.
[ ] Avoid using images of text unless the particular presentation of the text is essential (for example in logos or charts). If an image containing text needs to be used, then a text alternative should always be provided using “alt” text or longdesc as appropriate.
[ ] Avoid adding text in images via CSS. Images placed with CSS cannot have “alt” text added.
[ ] Be especially careful that images are not used in place of meaningful page elements such as headings or navigational lists, which can help assistive technology users better comprehend pages. Do not use the “meta keywords” field to add keywords to pages.
While following the above principles, remember that providing images to complement text can be a useful aid to enhance comprehension for sighted users. It can also be especially useful for people with dyslexia or learning difficulties. As long as a text alternative is provided, do not ignore the potential for images such as illustrations, charts, and maps to act as communication aids.
Links
Creating links with regard to accessibility is essential for providing a smooth experience for users of assistive technology. Screen readers provide the ability to navigate through the links on a page; link text should therefore be descriptive and short, and should make sense out of context.
Empty link text is also an issue because the presence of the link may still be announced by assistive technology and cause confusion.
Broken links are a general usability issue for all users, but they can be particularly frustrating for users of assistive technology who will need to expend additional effort on identifying an alternative path to the information the broken link should have led to.
[ ] Make link text descriptive of the link destination.
[ ] Do not use short, non-descriptive phrases like “click here,” “more,” or “available online” as the entire link text. Link text should be meaningful enough to make sense when read out of context.
[ ] Don’t make link text longer than necessary to adequately describe the linked-to resource. Shorter links are easier for users of assistive technology to use.
[ ] Indicate when a link is to a non-HTML page (e.g., PDF) and indicate the file format and size. Include the information on file format and size within or directly after the link (e.g., Strategic Plan 2014-2017 (PDF 115Kb)).
[ ] Ensure that you have no “empty” links in the code without visual link text (e.g., ).
[ ] Links with the same text that go to different locations must be readily distinguishable.
[ ] All linked images must have descriptive alt text. (See “Accessibility: Images.”)
[ ] Color alone must not be used to distinguish links from surrounding text. (See "Color.")
[ ] Ensure that there are no broken links on sites.
Navigation
[ ] Navigational mechanisms should always be presented in a uniform, well-structured, and logical order so as to avoid confusion or disorientation. Ensuring that repeated components occur in the same order on each page of a site helps users become comfortable that they will be able to predict where they can find things. This logicality helps users with cognitive limitations, users with low vision, and also those who are blind.
[ ] There should also be multiple ways to locate a particular web page, unless it is part of a process such as a check-out or search function. This multi-functionality makes it possible for users to locate content in a manner that best meets their needs. Users may find one technique easier or more comprehensible to use than another.
[ ] It is also important that navigation be accessible via a keyboard. When content can be operated through a keyboard or alternate keyboard, it is operable by people with no vision (who cannot use devices such as mice that require eye-hand coordination) as well as by people who must use alternate keyboards or input devices that act as keyboard emulators.
A consistent and predictable navigation scheme is a very important aid to website accessibility.
For example:
[ ] The search field should always be in the same place on each page.
[ ] “Skip navigation” links should be provided as the first link on every page. This premier positioning allows users to have a consistent way to quickly bypass header information and navigational content so they can begin interacting with the main content of a page.
[ ] “Skip to top” links should be provided at the bottom of each page so that keyboard users can easily jump to the top of the page when required. Ensure that your Content Management System (CMS) creates pages and links that search engines can crawl.
[ ] Ensure that navigation mechanisms are presented consistently across pages.
[ ] For example, the search function should not be labelled “search” on one page and “find” on another.
[ ] Include multiple ways of navigating a site, including at least either a search function or a sitemap as well as navigational links between pages.
[ ] Never use graphical text within your navigation scheme. HTML text should be used instead because it is resizable and easily read out by screen readers.
[ ] Ensure that the website can be navigated without using a mouse. This can be tested by pressing the tab key on your dashboard to see the cursor move through links, form fields, and objects. Keyboard focus should be easily trackable on the page. The selected link or control should be highlighted using a prominent rectangle or change in color with sufficient contrast.
Tables
Tables represent a complicated environment for visually-impaired users. That is because such individuals cannot easily see and understand the table structure. It is therefore necessary to add mark-up that will help screen-reader users navigate tables.
[ ] Using complicated, nested tables for layout may cause content to be rendered in the wrong order by screen readers. CSS should be used for layout instead.
[ ] On UNICEF sites, HTML tables (using the HTML
When using data tables:
(c) For simple tables:
(d) For more complex tables:
[ ] Where the header is not in the first row or column, use the “scope” attribute to associate header cells and data cells.
[ ] Where data cells are associated with more than one row and/or column heading, use “id” and “header” attributes to associate header cells and data cells in data tables.
[ ] Do not misuse structural HTML tags to create visual effects within tables. For example, do not use the table header tag to create bold formatting on text that isn’t a heading. Instead use CSS to control visual formatting.
[ ] Captions may usefully be added for screen-reader users. The “caption” element acts like a title or heading for the table. It ensures that the table identifier remains associated with the table, including visually (by default). In addition, using the caption element allows screen reading software to navigate directly to the caption for a table, if one is present.
[ ] Don’t use white space characters (e.g., space, tab, line break, or carriage return) to format text as tables or columns.
[ ] Don’t use the HTML
Titles and headings
Descriptive titles are important indicators of a page’s content and are the first thing a user of a screen reader will hear read aloud to him or her on a page. With headings, sighted users perceive them as a visual cue to the structure of a document – headings are often in a larger, bold font and are separated from paragraphs by blank lines.
Marking up headings appropriately ensures that this structure will be available for users of assistive technology. In a 2014 survey, 66% of screen-reader users said they used headings as shortcuts to navigate through pages, making this the most popular screen-reader navigation technique.
[ ] Always provide a meaningful, concise page title in the
[ ] Ensure you use correct heading markup for headings – e.g.,
,
,
,
. Do not indicate headings using just bold or larger text.
[ ] Include a single
heading on each page for the main page’s heading.
[ ] Make the text of headings informative and avoid having multiple headings with identical text (e.g., “More Details”) unless the structure of the page provides adequate differentiation between them.
[ ] To facilitate navigation and understanding of the overall document structure, use headings that are properly nested (e.g., h1 followed by h2, h2 followed by h2 or h3, h3 followed by h3 or h4, etc.).
Video
Providing a text transcript for all videos and audio files guarantees a basic level of access to the information being communicated because textual content is more easily manipulated by assistive technologies. Transcripts are also useful for SEO, since they give search engines text to index.
Captioning videos with dialogue is an essential service for users with a hearing impairment, but it can also be useful for people whose first language is different from that of the video or for users who need to access the video with the sound off – e.g., in a noisy environment without headphones. It is also essential to consider the keyboard usability of the video or audio player technology you use, since many assistive technologies rely upon the keyboard when viewing the content.
[ ] Supply closed caption files of any dialogue when you upload a pre-recorded video.
[ ] Provide a descriptive text transcript of any video or audio file.
[ ] Provide clear instructions for using video or audio content. Do not create pages with nothing but an embedded video on them. If you do so, people without the appropriate viewing technology will only see an empty page. Provide information on the page about the content of the video (which will also be beneficial for SEO).
[ ] For videos hosted on UNICEF’s websites, never play videos automatically when a page opens. The video audio will run at the same time as the user’s screen reader audio and the user will need to search for the controls on the page to stop the video.
[ ] For videos hosted on UNICEF’s websites, avoid flashing or flickering content. Videos with content that flashes more than three times in a second may trigger migraines or induce seizures in users with photosensitive epilepsy as well as other photosensitive seizure disorders.
Good to cross-reference with the documentation on accessibility for wagtail.