WCAG 3 is intended to be easier to understand and more flexible than WCAG 2. The flexibility is to address different types of web content, apps, and tools — as well as organizations and people with disabilities. The goals for WCAG 3 are introduced in the Requirements for WCAG 3.0 First Public Working Draft, which was also published today. WCAG 3 proposes a different name, scope, structure, and conformance model.
WCAG 3.0 is designed to be easier to learn, and for its results to better reflect the experience of people with disabilities on the web. This has resulted in a structure for WCAG 3 that is substantially different from the WCAG 2.x series. Let's look at some of these new structures.
Perhaps the most notable proposed change for WCAG 3.0 is the change from using success criteria to outcomes. Where success criteria were true-or-false statements about the content of a web page, an outcome in WCAG 3.0 is a statement about the need of certain users for specific types of content. Outcomes are not true-or-false statements, rather they are answered with a rating from 0 (very poor) to 4 (excellent). These scores can then be combined with the scores of other outcomes to determine the level of accessibility. This allows for a website to have some issues while still meeting a level of conformance.
In addition to a rating, each outcome defines what is considered a critical error for that outcome. For example, a critical error for text alternatives of images are images without a text alternative which prevent a user from completing a task. A website can have a small number of accessibility errors, but if it has any critical errors it does not conform to WCAG 3.0 at any level.
Instead of using levels A, AA, and AAA, WCAG 3.0 has the conformance levels bronze, silver, and gold. In the first draft of WCAG 3.0, most of the focus has gone into the bronze level. This level will be roughly equivalent to level A + AA of WCAG 2.1.
There is a lot of work left for WCAG 3.0, so don't expect to be using it any time soon. While experimentation and feedback are always appreciated, it is not recommended for anyone to start using WCAG 3.0 in earnest until it is published as a W3C recommendation. The earliest this is likely to happen is in 2023.
- Playwright has a class with "methods for inspecting Chromium's accessibility tree", which might be interesting for adding accessibility checks to end-to-end tests.
- Please use the
Translation tools like Google Translate may offer to translate contents of a page if the language defined in the
<html>element is not the same as the default language in the browser. It seems it doesn't matter in which language the page is actually written, what counts for Google Translate is the value of the
You could use something like a11y.css to debug your document or create your own debug.css and add tests you want to run in your development environment. "Tests" sounds fancy, but it's just a bunch of selectors that show a big red border or other visual indicators, if there's an error.
The latest versions of Edge, Chrome, and Opera all support
inertwhen experimental web platform features are enabled. Firefox support will also be landing soon! The one outlier is both desktop and mobile versions of Safari. I'd love to see Apple implement native support for
inert. While a polyfill is available, it has non-trivial support issues for all the major screen readers. Not great!
We can use the CSS repeat function with
grid-template-columnsin order to create an intrinsic grid which will generate as many columns as fit in the given space. An example using this type of grid is available in my demo for live-coding css layout.
There are a number of methods to detect layout shifts due to web fonts, the most simple is to run your page through WebPageTest and use the filmstrip view. There is a toggle to show layout shifts, combine that with 'huge' screenshot images and a 0.1s interval to get a clear view of what is happening as your page renders (you can simply add this to the end of the URL:
&highlightCLS=1&thumbSize=600&ival=100&end=visual&text=000&bg=fff"). [...] You can also find layout shifts in the Chrome Developer Tools Performance tab, look for layout shifts attributed to text elements.
The dirty little secret of this blog post is that you can resolve layout shifts due to fonts with a single line of CSS:
font-display: optional. This directive lives in your font-face declaration and tells the browser to use a fallback system font if the web font is not available at the time of rendering text (plus 100ms). This means that on uncached page loads there is a chance that the fallback font will be used, but all subsequent page loads should be rendered with the web font, as it will be downloaded and available in cache.
Downloading one or two font files to render text won't have a massive impact on speed, downloading five or ten font files will! Ensuring that you deliver the minimum viable number of font files is the best way to ensure that the browser has them available at layout, thus reducing the likelihood of FOUT layout shifts.
[...] Font stacks will often have many or all of these formats available, but you really only need
woff2. The newer format is around 30% smaller than
woffand is supported in all modern browsers. Supporting only
woff2will make it more simple to apply some of the other optimisations recommended, such as subsetting.
tabindex="0"should be applied to any non-interactive element that has had CSS' overflow property applied to it. This will allow people using a keyboard to navigate to, and scroll around the overflowed content.
[...] relying on solutions provided natively by browsers enables you to benefit at low cost from the expertise of the community creating web standards. These solutions generally have the advantage of using less code, thus reducing maintenance efforts for a development team (for example, no need to update the libraries used). In this article, we will explore some of these native solutions that are available to the majority of your users.