Accessibility Statement

Once the textual content for the images is planned, the developer should add it using the HTML alt attribute, or set up the CMS in a way that allows others to enter this content.

This is ideally tested using a screen reader to check if the user experience for blind people is as good as for other users. Otherwise, it’s possible to right-click on the element and click "Inspect", to see the element’s content with the web inspector.

Developers should add an empty alt attribute to images that are added for decorative purposes (or set up the CMS in a way that allows this).

The best way to test the website for alternative texts is to use a screen reader (since it also gives an understanding of the user experience for blind users). A faster way is to right-click on the element, click "Inspect", and then look for its alternative text in the code.

Developers should always use the right heading elements (h1, h2, h3, h4, h5, or h6) to implement titles.

This can be tested by right-clicking on the element, clicking "Inspect", and checking the HTML element used for the title.

Lists should be implemented using the HTML element <ul> or <ol> as a parent element and all of its children should be <li> elements.

To check if this condition is respected you can right click on the element, and click on "Inspect". Google Lighthouse is also useful to quickly check basic HTML error structures such as this one.

The HTML markup elements <tr>, <th> and <td> should not be used to achieve a specific layout, but are reserved for displaying tables on a website.

CSS properties such as display: flex or display: grid are better suited to achieving layouts.

To check if this condition is respected you can right-click on the element and click on "Inspect" to see if the elements <tr>, <th> and <td> are used.

Designers can accidentally do a few things that can make this condition harder to fulfill, e.g. arrange elements in a different order for different breakpoints. A sensible sequence should be maintained in the design even with different arrangements on the screen.

Developers should keep this condition in mind while implementing the layout, to know the content sequence should be logical in the HTML code itself (which element comes after which one), not only on how it’s displayed on the screen.

The best way to test this condition is to go through the website using a screen reader. This can also be checked by inspecting the website and looking at the element’s sequence in the code. To make it easier, it’s also possible to view it using the accessibility tree.

If the referencing of an element on the website is to be highlighted in text elsewhere (e.g. the link to the website's shopping cart), the design must ensure that the referenced element is designed in such a way that it can also be described using features other than purely visual ones.

For example, the textual reference "You can access the shopping cart in the top menu on the far right via the shopping cart symbol" would not be described in an accessible way. The element must therefore contain other features that can be described. For example, the shopping cart button should also have the label "Shopping cart" so that the description text could read: "You can access the shopping cart in the main menu via the button labeled »Shopping cart«".

Unfortunately, testing that this condition is fulfilled is a very lengthy and manual process, since it is needed to go through the entire website and read all the content.

It should be possible to use the website in landscape mode (which is mostly the case while creating responsive websites). This can cause issues with some designs (for example, in the figures portfolio website, the menu is in a fixed position, it could cause issues to use it in landscape mode, if there’s not enough space in the screen height to open it).

Some designs do not have enough space to be used in landscape mode and should be able to adapt (e.g. by using flex-wrap, limits in heights, limits in widths). The menu of the Figures portfolio needs to have enough space on the landscape mode as well (Initially, the design was planned for mobile in portrait mode only).

To test this condition, you can use the website on mobile, in landscape mode.

Designs should not rely on color (e.g. if there’s a graphic with colors, there should also be patterns, which serve as replacements for the colors).

Go through the website using an online tool to simulate color blindness (like the Web Disability Simulator), and check if any information is lost (or difficult to perceive) because it was conveyed only through colors.

The easiest is to test color combination contrast, at the beginning of the project, in the style guidelines. This can be done with a tool like Colour Contrast Analyzer. The contrast should be at least 3:1 for big text (with a size of at least 24px) and at least 4,5:1 for smaller font sizes. The tested colour combination can then safely be used in the design.

To check the contrast of the text with its background, in the entire website, a tool like Colour Contrast Analyzer can be used. It should have a minimum of 3:1 for big text (with a size of at least 24px) and at least 4,5:1 for smaller font sizes.

For some designs, it can be difficult to meet this requirement, e.g. for text that is overlaid with SVG graphics. Another difficulty is when the design needs to fit the screen height and the content overflows when zooming to 200 %. Another example is the Figures website menu, which overflowed the screen when opened and zoomed to 200 %.

To allow the text to scale properly, a dynamic unit like rem or em should be used for font sizes (instead of a fixed unit like px).

This condition is quite easy to test: all that is needed is to go through the entire website while it’s zoomed at 200 % and check that all of the text is scaled properly and that all functionalities still work.

This condition can make it more difficult to create some designs. For example, the animation of the Figures logo for the Figures portfolio was originally created as a Lottie animation. Unfortunately, Lottie animations, like images, can not adapt to user needs like text can. The solution used instead is an SVG, with a color set to “currentColor”. Setting an element color to “currentColor” allows it to have the same color as the text. This means that if the user changes the color of the text, it will change at the same time.

Images or Lottie animations should not be used as text. If an SVG element is used to replace text, it should fulfill the same conditions as the text does: have its color change dynamically when the color of the text is changed in the browser’s settings (by using a dynamic color property of “currentColor” instead of a fixed color property like “white” or “red”, and by specifying the text that the SVG represents in a hidden span element for screenreaders can read). You can use the home button Figures logo in the Figures portfolio as a reference.

Go to your browser settings and change the current text color and background color to a different one. Make sure that the settings to override the colors of the website is set to always. Check if everything is still visible on the website. Right-click the element and click on "Inspect" to see if the text content inside of it corresponds to the visible text (the text inside of the HTML element can be longer than the visible text, to give more precision, but the beginning needs to be the same so that users can activate it using vocal commands).

Most websites will fulfill this requirement since it’s part of creating a responsive layout.

Check the website by a width of 320px (it’s generally easier to resize the browser window, or use the size simulator tool since most smartphones will have a width slightly superior to 320px).

The easiest is to test color combination contrast, at the beginning of the project, in the style guidelines. This can be done with a tool like Colour Contrast Analyzer. The contrast should be at least 3:1. Some other accessibility rules require a higher contrast, like the text, which should have a minimum contrast of 4,5:1 if it has a small size.

To check the contrast, every color combination (of graphic and graphic control elements) can be checked with a tool like Colour Contrast Analyzer. It should have a minimum of 3:1, but can be higher (4:1, 5:1…).

Some designs can make this condition more difficult to fulfill, if there’s no margin planned for more spacing. For example, the text used in the "Moore und Auen" project, on top of the SVG graphics (e.g. treemaps) is made to fit the text in it exactly, and does not adapt to different text sizes of line-heights.

Go to the browser settings, change the text spacing to significantly higher values (text line-height to a distance of 1.5 times the font size, the spacing after paragraphs to 2 times the font size, the letter spacing to 0.12 times the font size and the word spacing to 0.16 times the font size), and see if everything on the website still works properly.

Most interactive elements (e.g. links, buttons) are by default usable without a mouse. Problems arise when important website functionalities are implemented using custom JavaScript for mouse interaction (e.g. for custom UI widgets or for navigating a 3D scene).

Go through the website using the keyboard (generally using the tab key), and see if every interactive action is still possible (navigating to a link, pressing a button…).

No keyboard traps should be created (they are generally created through JavaScript, e.g. by modifying the tab index of some elements or making modals appear).

Try going through the entire website with the key tab (while triggering functionalities like navigating to links or clicking buttons…) and check that the users do not get stuck anywhere while navigating with the tab key.

A pause button should be provided for repetitive animations. The extent to which this applies to animations that react to scrolling progress (scrollytelling) has not yet been sufficiently clarified.

Go through the website and check that it’s possible to pause all animations which last longer than 5 seconds.

Do not plan any animation that could flicker more than 3 times per second.

Go through the website and check that there’s no animation flickering more than 3 times per second.

A skip link should be added so the user can skip repetitive elements, like the menu. It does not need to be planned into the design, since this link can be invisible. It only needs to become visible when it is currently focused (using the CSS selector focus-visible). See the skip link added to the Figures portfolio, as a reference.

Navigate through the website with the tab key and check if it’s possible to skip repetitive elements, which are on multiple pages (like the menu).

Pages should have a title added to their metadata. The title used for the document should be the same or similar to the h1 title of the page.

Look at the title of the pages of the website (in the browser tab or in the preview thumbnail which appears while sharing the link) and check if it’s possible to guess the page content based on the title (ex: project Wind City).

Some designs can make it difficult to know the element’s order (for example, if it is different on mobile and on desktop, it will be more difficult to implement).

Go through the website with the tab key and check if the element focus happens in the expected order.

This concerns the client since they will give the textual content, and inside of it, the links should clearly indicate their target (e.g. "Read article about East Germany in 1967"). The link’s name (the text content in its HTML element) can be different from the displayed name (so that it’s more precise if users go through the website using a screen reader) but the beginning of the link should stay consistent (e.g. if a button has “Show app” as its visible text, its text can be “Show app Wind City” but not “go to website WInd City”).

Since the links are interactive elements, it’s possible to find them by navigating using the tab key (instead of having to read all the text). Check that the name of the link is meaningful (e.g. "Click button", "Learn more" or "Click here" are bad names for links). If the visible text of the link is not meaningful, you can also check if the text in the HTML is more meaningful or not by right clicking it and then clicking on "Inspect". For example, the “Show app” button in the Figures portfolio project page fails that criteria. But if you inspect it, you can tell it specifies the name of the website it leads to (e.g. “Show App Wind City”).

There are multiple ways to create alternative access routes in a website (e.g. search bar) but the easiest to develop is the sitemap. So it’s always good to plan a sitemap for a website.

Check if there are multiple ways to access the same links (if there’s a menu and a sitemap it should be fine, but make sure the sitemap has all of the website’s links on it).

Testing this is time-consuming and manual, as it’s necessary to go through the entire website and check if all headings and captions appropriately describe the content they’re associated with.

Most of the time, the focus position will be indicated thanks to the default style of the browser. In some cases, however, it will be necessary to plan the CSS style based on the focus style. At other times, it can be useful to modify the focus style of the website, to make it correspond with the rest of the design, or make it more visible. For example, the focus style of the menu element corresponds to a white line (made with a shadow) and a purple line, This is because the menu element is fixed, and sometimes displayed on a purple background, and sometimes on a white background.

Go through the website with the tab key and check that the position of focus is always clearly visible (with a contrast ratio of at least 3:1 to its surroundings).

If there is an action that the user needs to be able to cancel, a concept or design needs to be planned for it.

Check that all actions on the website can be canceled or undone.

The lang attribute of the page should be added to the website (and be dynamic if it’s a multilingual website, e.g. German version lang=”de”, English version lang=”en”).

Right-click on the website and click "Inspect" to find if the document has a lang attribute. It’s also possible to use Google Lighthouse to check that it has not been forgotten (but Lighthouse can only check if the lang attribute is missing or not, it won’t be able to tell if it corresponds to the right language).

The HTML structure in the website (and in the CMS) should be set up in a way to make it possible to add elements with lang attributes (by using inner HTML or adding fields for optional lang attributes, as in the CMS of the Figures portfolio website).

This test is very time-consuming, as it requires going through the entire website to find words, sentences, or sections that are in a different language than the main language of the website and checking if they have the correct lang attribute by right-clicking them and clicking "Inspect" to check the original HTML code.

The focus state should not be used to trigger any unexpected event (e.g. opening a pop-up).

Navigate through the website with the tab key. The only event that should happen is the newly focused element getting highlighted.

The order of elements in the website should stay constant (the menu links should appear in the same order on all pages). The interactive element (links, buttons…) appearance should also be consistent (showing links by underlining them and using the same colors/shapes for the buttons).

Go through the website and check if the navigation elements stay consistent (in the order in which they appear and visually).

The names should be implemented consistently inside the website. This concerns the person who is in charge of creating the textual content (since the website can have internal links inside of the text) but also developers since they can ensure that the text in the menu, footer, document title, URL, and so on stay consistent.

Go through the website and check if the various names referring to the same website page (in the menu, footer, text links, the various interactive elements in the website, in the page title, and the URL) are consistent.

If an HTML element doesn’t have an opening or a closing tag, it’s generally highlighted as an error in the code directly. The same goes for duplicate attributes. Adding identical IDs is a more common mistake. Nesting elements incorrectly is also a more frequent mistake and generally happens for these three reasons:

• lack of knowledge on which HTML elements are inline and which ones are block elements (inline elements can be used inside of block elements but not the other way around)
• injecting HTML inside of a <p> element
• forgetting to update an HTML structure when the design gets updated.

This can be checked by right-clicking on the website, clicking on "Inspect", and checking the HTML structure. A much faster method is to use Lighthouse to see if it reports any errors.

This condition concerns buttons and links that do not have any visible text (since they use an icon or other visual sign instead). To give them a name that can be read by screen readers, it’s possible to add a span element with text inside and hide it with CSS. Text nodes are better than attributes since it’s easier for tools (like translators) to access them. Adding a role is mostly necessary for custom HTML elements (since others, like buttons and links already have their roles specified) and value is important for interactive elements like inputs and sliders.

To test this, it’s possible to inspect the website by right-clicking it and clicking "Inspect". It’s also possible to use Google Lighthouse to make a basic check of the HTML structure.

As with the other rules modifying the text size, this will not always be possible if the space for it is not planned in the design (ex: in the SVG of treemaps in the Moore und Auen project, the space for the text was not planned for it to be able to augment in size).

For this condition to be fulfilled, it’s important to not use any hard-coded values for the color SVG and other elements that should have a dynamic color. This is because if a SVG has a hard-coded black value, and the background color is changed to black, it becomes invisible. On the other hand, if the text color is set to black, and the SVG color is set to the same (with the CSS property fill: currentColor) when the text color is changed (through the browser’s custom settings), it will change at the same time.

Customize the website settings (background color, text color, text size, display of the focus cursor, and units of measurement) and check if everything is still working properly.

As this is textual content to document the accessibility features, this concerns the client (with the collaboration of the agency to collaborate on the list of accessibility features).

Check that the documentation (including the accessibility statement page) properly clearly explains all accessibility features.

To make the documentation accessible, the design needs to follow the accessibility rules (see other accessibility rules on this page).

To make the documentation accessible, the development needs to follow the accessibility rules (see other accessibility rules of this page).

To make the documentation accessible, the content needs to follow the accessibility rules (see other accessibility rules of this page).

Perform the test methods specified for the other accessibility rules.