inklusivo

2026-01-23T09:37:04Z

A glossary of web accessibility terms

2026-01-23T09:37:04Z

Web accessibility has lots of specific terms, abbreviations and other jargon. This glossary clarifies some of them, and more. Further resources are added where available.

This page is very much a "living document"; it's intended to be updated and improved constantly. Your questions and contributions are much appreciated!
As it's due to change, bookmarking is probably more valuable than printing. You could also save some trees that way.

Blog

2026-01-23T09:37:04Z

Blog

The Scaled Accessibility Model (SAM)

This model defines what needs to be in place to create accessible and inclusive products. It does not matter whether you're aiming for mere compliance or something else entirely. It is a framework for the required processes and resources.
The Anatomy of an Accessible Text Field

Forms consist of so many parts that they're easy to get wrong. Let's dissect the text field.
How to make your colour palette usable for accessibility

How to make your colour palette usable for accessibility
QR codes and accessibility

QR codes and accessibility

2026-01-23T09:37:04Z

QR codes and accessibility

The Scaled Accessibility Model (SAM)

2026-01-22T00:00:00Z

This model defines what needs to be in place to create accessible and inclusive products. It does not matter whether you're aiming for mere compliance or something else entirely. It is a framework for the required processes and resources.

This model is how we work at inklusivo. We've translated decades of experience to a model that can support different organisations and goals. We don't like reinventing the wheel.
The Scaled Accessibility Model (SAM) sketches a goal state that can be guiding for creating roadmaps and setting up milestones. It aligns very well with the practice of backcasting: "if we want to attain a certain goal, what actions must be taken to get there?"

The model

Central to this model are the practitioners. They are the people who create and build. In the context of digital experiences this means people like developers, designers and content writers. It can translate to other (non-digital) practices as well. For practicality, we've restricted the scope of this article to focus on the digital.
The practitioners are like the engine of creation. Motivating, directing and facilitating practitioners is at the core of getting results. Modern leadership is servant leadership.

How do we do this? Our method comes from experience and aligns with the book "Drive: The Surprising Truth About What Motivates Us" by Daniel H. Pink. This bestseller explains there are 3 factors that motivate people: autonomy, mastery and purpose. SAM was not invented to copy this practice. It comes from experience and insights, but does align perfectly.

The following sections cover the various parts of this model:

The resources that practitioners depend on
The skills that practitioners depend on
The direction that practitioners get from a mission/vision, from requirements and mandate from management, and from peers through community and culture

Resources

In computer science, garbage in, garbage out (GIGO) is the concept that flawed, biased or poor quality ("garbage") information or input produces a result or output of similar ("garbage") quality.

― Garbage in, garbage out on Wikipedia

You might be familiar with the expression "garbage in, garbage out". It's very hard to build good things with bad parts. It's hard to build a straight tower with crooked building materials. Or to build a solid building without a strong foundation.
Accessibility is not very different in this. It's very hard to build an accessible website when the component library or Design System doesn't offer the right building blocks. It's hard to design a contrasty experience without a useful palette. And it's very hard to test that same contrast when you don't have the right tools for testing.
If you want to make it easy to produce accessible experiences, the route to accessibility should be paved and without barriers. If accessibility takes too much time, effort or energy, verify that proper resources are offered.

This need for resources aligns with the need for Autonomy as mentioned in the book Drive. By giving people proper resources, you give them the means to act autonomous. They can strive for accessibility on their own as they have everything they need.

Resources might include:

Tooling
Branding
A component library
A Design System
Documentation

For example, the accessibility guild at VodafoneZiggo has a list of tools that are tested and approved for use on their hardware. No demotivating search for tools that may or may not work, but a shared effort that makes things easier for everybody.

Skills

Resources are great, but you need to know how to utilise them as well. Skills need to be built and supported. This can be done in many ways. It can come from conversations with others, onboarding, internal education, external training and even good supportive documentation can help.

The need for skills aligns with the need for Mastery as mentioned in the book Drive. By supporting people to improve their skills, you give them the means to obtain mastery. They can apply and display their skills in creating accessible experiences.

Skills can be supported with:

Training
Awareness (general accessibility training)
Documentation

For example, the accessibility guild at ING has their own internal training program. The documentation of their Design Systems does not just tell people what to do, but also why certain things are important for accessibility. Two points that both contribute to skills.

If the effort to create accessible products is considered hard and complicated, verify that proper skills are facilitated.

Direction

If a person is like a captain, then they now have the right boat and equipment, and the skills to get it moving. But where should they be going?

People appreciate direction. This aligns with the need for Purpose as mentioned in the book Drive. It is about the desire to do something that has meaning and importance.
Meaning can be fully intrinsic. A person can have an ethical drive to make accessible experiences and build something that is inclusive. This can be further strengthened, awakened or fostered by having a community and culture of accessibility. A group of people with the same purpose can share experiences and frustrations. Together they can be more effective, often even negating issues with resources or skills. A strong drive can overcome barriers. If you recognise yourself in this, find people who are like-minded.

Importance can also be extrinsic. By making accessibility part of requirements, it is communicated as being something of importance. Making clear what an organisation values is adding importance.

Direction can come from:

A company-wide mission or vision
A mandate from management
Requirements
Intrinsic motivation
Community and culture (be part of online communities and/or visit meetups!)
Feedback from users

For example, the vision of IKEA is "to create a better everyday life for the many people". That's a great vision that ties in perfectly with creating inclusive products and services.

If there is a clear effort to create accessible products, but the efforts come across as ad hoc, disorganised or uncoordinated, verify that proper direction is given and supported.

The role of management

A lot of this model focuses on the practitioners, and their needs. The goal of management is the model. The goal is to make sure the model and its factors are in order. Make sure everybody has the right resources and skills. Give people a mandate, add accessibility to your requirements, and make sure people are connected with their colleagues. Maybe join that community to show people they are being seen (in a good way).
Facilitate intrinsically driven people and guide their individual efforts to support. It is your task to make sure all aspects are taken care of.

Conclusion

SAM sketches a picture of what needs to be in order for people to flourish and build accessible. This model was previously presented at NCDT in 2025 as Scaled Accessibility: How Big Dutch Companies Manage Accessibility. This article expands on that thanks to the eyes, minds, feedback and insights of other people. If you want to work with this model (either with or without us) please let us know. We've got more where this came from, and your shared experience can only improve it further!

The Anatomy of an Accessible Text Field

2025-12-19T00:00:00Z

Forms are complicated. Or rather, forms consist of so many parts that they're easy to get wrong. Talking from experience: the odds of a website with forms having accessibility issues are nearly guaranteed. The limited automated test of the WebAIM Million already finds issues with labels on nearly half of all pages.
Let's find out what we can do to avoid these and many other issues with forms. We're going to dissect the most common form-specific element: the text field.

This article gives you a starting point for designing and coding text fields. The solutions given are not the only way to meet accessibility requirements and user needs, but they do offer a solid and proven approach. These examples should help you meet compliance with WCAG 2 AA.
A form can consist of many more parts. This article does not focus on other elements or form validation. It touches upon a lot of WCAG criteria already, just by dissecting an invalid required text field.

The result

This is the "too long; didn't read"-version of this article. The resulting code should be something like this:

<label for="text-field">[Descriptive name] (required)</label>
<span id="hint">Put your instructions here</span>
<input type="text" id="text-field" aria-required="true" aria-invalid="true" aria-describedby="hint error" autocomplete="[to be determined]"></input>
<span id="error" role="alert">⚠️ The required field "name" is empty.</span>

Which should result in something with visuals like these:

Your version will probably look different when it comes to things like fonts, spacing and colours. Consider this a wireframe more than a visual design.

The elements

Let's go through all the parts that make up a text field.

The label

<label for="text-field">[Descriptive name] (required)</label>

The label is the element, both visually and in code, to name an element.

Action without a name, a who attached to it, is meaningless.

― Hannah Arendt

Everything needs a name. A name helps you identify an element. It helps you distinguish one from another. It can tell you what its purpose is. It also tells you how to refer to an element. Common labels include texts like "Name", "Password" and "Email".
WCAG SC 3.3.2 Labels or Instructions requires you to provide labels or instructions when user input is required. In theory, this could be any <span> or <div>. WCAG SC 1.3.1 Info and Relationships requires that it's marked up properly. The most appropriate element to do that with is the <label>-element.
Visually, a label and a text field should have a clear relationship. By adding the for-attribute, you create a relationship between the <label> and the <input> in the code as well (which satisfies WCAG SC 1.3.1). This works by using the id of the <input> as a value. Added bonus, the label is now interactive. When activated, the focus is put on the text field.
By creating this relationship, you also give the text field an accessible name. Naming a text field is needed for WCAG SC 4.1.2 Name, Role, Value. Using this method to name a text field results in the visible label being the same as the name in the code. This satisfies WCAG SC 2.5.3 Label in Name.
There is also a success criterion related to the size of interactive elements. By making the label at least 24 by 24 pixels, you won't have to consider WCAG SC 2.5.8 Target Size (Minimum).

As you might expect from what's written so far, the label needs a nice descriptive name. This is also mentioned in WCAG SC 2.4.6 Headings and Labels. It does not need to be unique across pages. It does need to be consistent to satisfy WCAG SC 3.2.4 Consistent Identification.
For this example, we assume the text field is required. This is the ideal location to visually indicate a text field is required. A simple "(required)" is a great way to do this. This is much easier to understand than an asterisk (which might introduce new issues).

The hint or instructions

<span id="hint">Put your instructions here</span>

Form fields often, but not always, have additional information. This could be about the expected format of the input, like how to format a date. It can also state specific requirements, like the number of characters in a password.
Any additional information, besides the name/label, that is known before the user provides input, should be put into this area. This means you should state password requirements before validation. This avoids frustrating guessing games where users provide input, they get feedback, they adjust their input, they get new feedback, they adjust their input again, and so forth. Such an opaque feedback loop makes a form unusable.
Like the label, instructions can help satisfy WCAG SC 3.3.2 Labels or Instructions.

The text field

<input type="text" id="text-field" aria-required="true" aria-invalid="true" aria-describedby="hint error" autocomplete="[to be determined]"></input>

We add type="text" to declare this input to be a text field. There are different values that might be relevant for you. Use type="password" for a password that will be obscured. If you can add a button to toggle visibility of a password, that's great. I wish this were a WCAG-requirement and/or implemented in all browsers.
Watch out with values like type="number" as they can limit the keyboard that is shown on mobile and can introduce different interactions like spinners.
The id is important. We've used that value in the for-attribute of our label. That's how we've created a relationship in our code.
aria-required is a way to indicate this field is required. It is also mentioned in WCAG as Technique ARIA2:Identifying a required field with the aria-required property. It's related to WCAG SC 1.3.1 Info and Relationships, WCAG SC 3.3.1: Error Identification and WCAG SC 3.3.2 Labels or Instructions. Unlike the HTML-attribute required, aria-required does not trigger built-in validation messages.
Likewise, aria-invalid can be used to indicate an invalid field. This is mentioned in WCAG as Technique ARIA21:Using aria-invalid to Indicate An Error Field and is related to WCAG SC 3.3.1: Error Identification.
aria-describedby adds a description to the text field. Screen readers often pronounce this (or these) after the essential name, role and values of an element. The attribute takes an "ID reference list" which means it can concatenate multiple IDs. In this case we refer to the hint or instructions, and any error message that might be present. We do this with WCAG SC 1.3.1 Info and Relationships in mind.
The autocomplete-attribute helps people input information they have used before. It identifies what type of input is expected. All possible autocomplete-values are listed in the specification. If there is no fitting value, consider using on instead. This way a tool like a browser or password manager can still attempt to assist the user, but it might use other metrics or information besides the autocomplete-value.

And whatever you do, don't use placeholders. Placeholders in Form Fields Are Harmful.

The error message

<span id="error" role="alert">⚠️ The required field "name" is empty.</span>

The error message needs an id so it can be referred to by aria-describedby. We do this for WCAG SC 1.3.1 Info and Relationships. The role="alert" gives the <span> semantics, and is there to announce the error much like aria-live would do. This makes sure errors are harder to miss, and helps with WCAG SC 4.1.3 Status Messages.
Then there's the content itself. Often we start with an icon, pictogram or whatever image. A lot of people appreciate visual cues like these. Making sure to give them an alternative where needed (WCAG SC 1.1.1 Non-text Content). Preferably something that describes what the image communicates (a word like "error" or "warning") and not a description of the image.
An image also helps with WCAG SC 1.4.1: Use of Color. It avoids a form field where only colour differentiates a state like an error.
There's a book to be written about what makes an error message good. As a starting point, don't tell the user anybody they (could) know already and support them in fixing the issue. This means it should be human-readable, helpful and rules out issues with formatting. The formatting can be communicated beforehand.

Other considerations

There are considerations for the visual design as well. Hopefully obvious are WCAG SC 1.4.3 Contrast (Minimum) and WCAG SC 1.4.11: Non-text Contrast. Both text and non-text should have sufficient contrast. This is another reason to avoid placeholders.
The order of elements in this article is not accidental. Putting label and instructions first reduces the odds of people missing them before reaching a text field. This assumes using a left-to-right language. It also avoids an on-screen keyboard blocking this information when inputting information.
Make sure elements are grouped close together. When they're far apart, they're easy to miss for people zooming in (both digitally and using a magnifying glass).
When text fields are used to input information that needs to be verified, like a validation code through SMS, make sure verification happens after submission. Pages that "change on their own" can be very confusing and conflict with WCAG SC 3.2.2: On Input
While this article focuses heavily on web and HTML, the same principles apply for mobile and native code.

Conclusion

Forms can be extensive. They're fragile when it comes to both Web Accessibility and Usability. Both many things can be done wrong, and many parts can be built better than how other build forms.
The text field specified here is your starting point. Take this and iterate on it for your own use cases. Improve and adjust when you are certain you need to deviate. Otherwise take this example as your accessible default.
A form field is much more than just text fields, but you can't build accessible forms when the building blocks fail already. Solidify your foundation before building further.

How to make your colour palette usable for accessibility

2025-12-11T00:00:00Z

Colour palettes are the building blocks of visual design. Having a practical palette makes a world of difference when creating accessible experiences. But how can we make our palettes as usable as possible?

What does WCAG say about colour and contrast

The Web Content Accessibility Guidelines (WCAG) mentions two contrast ratios. There’s 4.5∶1. That’s the minimum contrast requirement for regular text as mentioned in WCAG Success Criterion 1.4.3 Contrast (Minimum). This means that when you measure the contrast of regular text on a background, it should have a contrast of at least 4.5∶1.

You can measure this contrast in the developer tools of your favourite browser like Firefox or Chrome. You can also measure it inside Figma. If your software can’t measure contrast, then there are external tools like the Colour Contrast Analyser.

The other contrast ratio that WCAG mentions is 3∶1. This is the minimum for large text, which is defined as text that is 14 points (about 18.5 pixels) and bold, or 18 points (24 pixels).
It is also mentioned in WCAG Success Criterion 1.4.11 Non-text Contrast. It is the minimum contrast for User Interface Components (things like form elements, buttons and links) and Graphical Objects (like icons and parts of charts).

Note 1: Every state of a component (like a focused button or a visited link) should have enough contrast with the background. States do not need to contrast with other states of the same component.

Note 2: When discussing User Interface Components, the part that makes the component recognizable is the part that has contrast requirements. For example, a button with a light gray outline on a white background might be very low contrast. But if it contains contrasty dark gray text that makes it recognisable as a button, then it meets contrast requirements.

How to simplify WCAG-compliance for designers

For many designers, their colour palette is like a toolkit. It helps when they’re not severely limited in the tools they can pick. And it helps when they know when each tool can be used or applied.
To translate this to WCAG-compliance: It helps when designers have a clear selection of colours, with guidance on when they can use which.

Visualizing the usability of a palette

My favourite tool for achieving these goals is Contrast Grid by Directed Edges (formerly, EightShapes).
In this tool, you can enter a set of colours. It will generate a grid (hence the name) with those colours. It will show the contrast ratios of all combinations of colours.
If you enter a palette of 6 colours. It will generate a grid of 36 (6 times 6) squares. It will show you the contrast of each of those 6 colours, when combined with one of the others (and itself).

See for yourself: Contrast Grid with white, off-white, light gray, medium gray, dark gray and black.

What does it say?

From top to bottom in the column with white on top. Off-white on white gives a very low contrast of 1.1∶1. Medium gray gives 4.5∶1, which is enough for complying with regular text. Dark gray gives a respectable 7.4∶1 on white. Black on white gives the maximum contrast of 21∶1.
Taking off-white as a background gives slightly lower values, as the contrast is worse on a less bright background.
Besides the numbers, the grid also has labels. DNP means Does Not Pass. This combination is low contrast and is not usable in any situation. AA18 means the contrast is enough to comply with WCAG for large text (3∶1 or more). This is also sufficient for user interface components. Anything marked AA can be used for regular text. AAA means it’s sufficient for regular text following the stricter AAA-level of WCAG.

What we can do with this part 1: improve

When you generate a grid like this, and see a lot of DNP, that means your designers have very few combinations to work with. This is where the tool will help you out. If you see some shades just below the minimum for compliance (2.8? 2.9?), you can change them slightly and improve contrast. Of course, 3∶1 is a minimum set by WCAG, but you’re free to have your own goals here.
The same goes for regular text. Maybe you can improve it to work not only on a white background, but also that off-white you’re using everywhere, or that slightly colourful bright background you’re using.
It’s also possible to see shortcomings in your selection of shades. If you have white, off-white, and your next darkest colour is medium gray at 4.6∶1, maybe add something in between for more flexibility.
Getting this visual representation of your palette and the useful combinations can really help you understand how rich or poor your toolkit is. It’s not impossible to have a very large grid with very few usable combinations. And with just a bit of fine tuning, this can be changed a lot.

Now that you have your ideal palette, it’s time to put it into action. The tool can help with this as well. Take the output of the tool, and put it somewhere where designers are. The data can be put in an Excel. But it might get overlooked. Maybe you have a shared Figma- or Penpot-file where this information would be fitting. Or you have a Design System with an extensive page on the colours you use. It would be perfect there. And in addition, you can even encode it in your Design System and its tokens.
Don’t tell people what they can’t do, but make it clear what options they do have. And showing all usable combinations is doing just that!

I’ve followed the steps, am I now WCAG-compliant?

WCAG is more than contrast, and contrast is more than having a useful palette. But this does help a lot. Having a useful palette is the foundation of an inclusively designed brand. You can’t expect people to build inclusive experiences when their building blocks have issues.
The most common contrast issues that still pop up with a proper palette include:
Low-contrast placeholders in input fields: don’t use placeholders.
Custom form elements: sticking to native makes life easier. Be prepared to thoroughly test when you don’t.
Non-default states with low contrast: design and test beyond the happy flow.
Images being used as background: avoid text over images.
External tools, vendors and embeds that deviate: good luck. A challenge in tight process management and communication.
Non-consistent implementation of the palette: this might be a challenge beyond accessibility.

QR codes and accessibility

2025-06-01T00:00:00Z

Introduction

This is a guideline for printing QR codes. These guidelines are part technical, but there is a strong people-part to QR codes as well. QR codes are computer-readable and very much opaque for people. Not knowing what something is and/or does, adds a fear for many people. That fear can be a barrier for people.

Definition

A printed QR code (quick-response code) is a square two-dimensional barcode used for, in this case, representing a URL.

Checklist

Text - Always show the URL in plain text and add enticing microcopy that clarifies what to expect from the URL. Remove uncertainty and fear where possible.
Placement -
1. Preferred. When there is space next to the url, place a QR code with the text "QR code" in the center. This text clarifies there is a QR code present for scanning tools and for people who do not recognize QR codes.
2. Alternative. When horizontal space is not enough but vertical is plenty, place a QR code with the URL in the center.
3. When space is limited, print no QR code (but do print a URL).
Size - Width/height at least 2cm, and preferably around 1/10th of the scanning distance. – The technical minimum is around 1cm. Complex/long URLS (more data), error correction, sub-optimal printing and variation in user devices add a lot of uncertainty and variance. This makes double the minimum reasonable. https://www.qrcode.com/en/howto/code.html
Printing - Print on non-reflective and flat surfaces where possible. Reflections can optically break the pattern, and non-flat surfaces deform it.
URLs - Create the shortest human-readable URL possible (IE: domain.ext/text) without external shorteners. - External shorteners lessen trust. Longer URLs require more data and increase complexity of the QR Code. This makes them harder to scan and recognize. https://www.qrcode.com/en/about/version.html
Position - Place QR codes consistently and at the end of a message. - A QR code is used for exceptional URLs and acts like a call to action.
Target - The URL must be a website that works on all resolutions as QR codes are often scanned with phones. - (Shouldn’t be an issue in theory, as this is part of WCAG-conformance)
Test - Test the QR code before sending it out. - As the code can't be understood by looking at it, issues creep in easily.
Format - Use a black and white QR code with squares when possible. Set error correction to H (high) when possible. A different bright background is possible but impacts both scanability and recognizability. - This is the most conventional shape of a QR code. It is closest to following the standard (ISO/IEC18004). It is the easiest to scan because of contrast and formatting, but it's also the easiest to recognize. The error correction allows for damage and distortion (and removing the center).
Spec - Include an outline with the same color as the background, with a width of at least 4 blocks. – This is also called a quiet zone, as mentioned in the standard (ISO/IEC18004).
Spacing – Avoid multiple QR codes on the same page or surface. Multiple QR codes can confuse devices.

inklusivo

A glossary of web accessibility terms

Blog

Blog

The Scaled Accessibility Model (SAM)

The Anatomy of an Accessible Text Field

How to make your colour palette usable for accessibility

QR codes and accessibility

QR codes and accessibility

The Scaled Accessibility Model (SAM)

Table of Contents

The model

Resources

Skills

Direction

The role of management

Conclusion

The Anatomy of an Accessible Text Field

Table of Contents

The result

The elements

The label

The hint or instructions

The text field

The error message

Other considerations

Conclusion

How to make your colour palette usable for accessibility

What does WCAG say about colour and contrast

How to simplify WCAG-compliance for designers

Visualizing the usability of a palette

What does it say?

What we can do with this part 1: improve

What we can do with this part 2: share

I’ve followed the steps, am I now WCAG-compliant?

QR codes and accessibility

Introduction

Definition

Checklist