Posted on by Patrick H. Lauke in Design and development, Standards
Tags: WCAG
In this post, we cover updates we've made to our own site in order to better satisfy the requirements of the Web Content accessibility Guidelines (WCAG) 2.1 Level AAA.
Building on a WCAG 2.1 AAA assessment carried out by independent auditor Mallory van Achterberg in 2019, which included a few issues that had since been resolved, we identified the following shortcomings to fix:
Since the original assessment, we also produced a number of videos that are included in various blog posts. This brought a further consideration under AAA:
Originally, our site featured a few controls/links that did not satisfy the minimum target size requirements of 44×44 CSS pixels.
To satisfy the requirements of the success criterion, we made these elements larger. In our case, this was straightforward, as it had minimal impact on our relatively simple layout. All it took were minor CSS changes to set an appropriate minimum width and height.
Note that the Target Size criterion exempts targets that are in a sentence or block of text, meaning that the majority of links in the main content of our pages are exempt.
It can often be a challenge to find a suitable colour combination that passes the basic AA colour contrast threshold of 4.5:1 while working within the confines of a corporate identity colour palette.
The following table shows the breakdown of TetraLogical's corporate colours, and their colour contrast ratio against the off-white background we use for our site.
Most of our colours are designed to be used against a white/light background and, where necessary, only at large sizes (to satisfy either the 4.5:1 threshold for regular text, or the 3:1 threshold for large text).
In practice, the lighter colours are used for incidental and decorative purposes, and we only use the two colours with the strongest contrast (dark and light purple) for content. However, once we move to AAA, the only viable colour that meets/exceeds the 7:1 contrast threshold is the primary/dark purple one.
If we kept to the corporate identity palette, we would have to remove vibrant/dynamic colours for links and call-to-action buttons, making an almost monochromatic version (as far as text content is concerned) of our site. This makes the site work well for people requiring high contrast, but is less aesthetically pleasing and potentially more tiring and difficult to parse visually for others.
To try and square the circle for this issue, we took a pragmatic approach with our site's styling.
The current draft for CSS Media Queries Level 5 introduces a variety of new media query features, including a query for prefers-contrast. This allows developers to define specific styles based on a person's contrast preference.
We used a @media (prefers-contrast: more) { … } block to redefine specific colour combinations that failed the stricter AAA threshold, such as the colour of links, call-to-action buttons, pagination controls, icon-based social media links, and the various controls in our 3rd party blog comment system.
Here are a few examples showing our site's default styles and how things look when the prefers-contrast: more media query evaluates to true:
While this media query is well supported in modern browsers (see the "Can I use…" breakdown for prefers-contrast), not all operating systems currently provide an easily-accessible way to set this contrast preference in the first place.
At the time of writing, macOS and iOS have the best implementation for setting this preference at the operating system level. On macOS, the option to "Increase contrast" is found in "Settings > Accessibility > Display", while on iOS it's under "Settings > Accessibility > Display & Text Size".
Depending on which particular flavour/distro of Linux you use, a similar OS-level setting is available. For instance, in Ubuntu, you can find a "High Contrast" option in the settings app under "Accessibility > Seeing". At the time of writing, this setting seems to be only supported correctly by Firefox, but there are open bug tickets against other major browsers.
There is no separate OS-level option on Windows to set a preference for higher contrast. Instead, Windows 11 settings offer "Contrast themes" in the "Accessibility" section. A subtly renamed take on Windows' classic "High Contrast Mode", this allows people to choose from a series of predefined colour schemes with more distinct colours.
Applying a contrast theme does result in the prefers-contrast: more media query evaluating to true (which can be verified with a simple test such as this Media Queries Level 5 user preference test). However, just as with the "Windows High Contrast Mode" (WHCM) of old, this setting also forces most foreground and background colours to be replaced with the theme colours, so our high contrast tweaks are not actually displayed, nor necessary.
Authors do have a small amount of control over which are used when in high contrast/contrast theme mode using the force-colors: active media query. We'll cover this in a separate blog post.
Lastly, Android currently lacks any support for setting high contrast. While there is a "High contrast text" toggle in "Settings > Display > Display size and text" in the default Android OS and an equivalent "High contrast fonts" toggle in "Settings > Accessibility > Visibility Enhancements" on the popular Samsung-flavoured version of Android OS, these settings only affect the operating system itself. Regardless of this OS-level setting, browsers on Android always report prefers-contrast: no-preference, and the custom prefers-contrast: more styles are not applied.
While the current approach of having the AAA-conforming contrast ratio on-demand only, dependent on the prefers-contrast: more media query feature, only has partial support, it does strike a pragmatic balance between the needs of people that require very strong contrast, and those who find lower contrast and a more varied use of colour to distinguish page elements (e.g. static text from links), easier to read and understand. Support for this feature will improve as operating systems and browsers implement and/or surface this user preference.
The most recent change to our site centred on the various videos we use in blog posts and as learning resources. Per 1.2.6 Sign Language (Prerecorded), we provided versions of our videos which include sign language interpretation.
As we don't have the necessary resources in-house, we used a dedicated company specialising in sign language content creation to create signed versions of our videos. We also included links to the signed versions wherever we had previously embedded the non-signed versions.
For more information on this, see our recent blog post Adding sign language to videos.
This post gave an insight into how we updated our site to meet WCAG 2.1 Level AAA requirements for:
For more information about the Web Content Accessibility Guidelines, read our WCAG primer or browse our training courses and training programmes.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。