inklusivo

2026-06-23T08:18:52Z

QR codes and accessibility

2026-06-23T08:18:52Z

A glossary of web accessibility terms

2026-06-23T08:18:52Z

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-06-23T08:18:52Z

Blog

Live accessibility Q&A

Ask anything about web accessibility
Accessibility fundamentals

Why and how you remove barriers for people with disabilities
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

About

2026-06-23T08:18:52Z

We are inklusivo, an accessibility agency and foundation run by a community of inclusion and accessibility experts.

We believe two things:

Everybody needs to be included, including people with disabilities.
Those with lived experience know best what suits them: Nothing about us without us.

Contact

Live accessibility Q&A

2026-06-02T00:00:00Z

This Friday (June the 5th at 13:30 CET) we will have a live-streamed accessibility Q&A. Inclusive expert Erik Kroes is hosting, and will answer your questions about programming and design.

We will be going through an open source website (suggestions welcome!) and answer any questions along the way. Questions that are not a fit for the session can be answered afterwards.

The event will be live-streamed and recorded on Youtube. Live captions will be auto-generated. The captions of the recording will be adjusted where needed.

This is the first of 3 sessions and, depending on feedback and wishes, maybe more!

Mark it in your calendar and tune in at https://www.youtube.com/@inklusivo-video

Any further details will be shared through LinkedIn, Mastodon and Bluesky.

Accessibility fundamentals

2026-04-28T00:00:00Z

This is an introduction to accessibility: the removal of barriers for people with disabilities. It answers questions like "Why is accessibility important? and "How can I remove barriers?"

This introduction is relevant for a wide range of roles like management, design, development and writing. It is also a very valuable foundation for roles in communication and marketing, conversion, SEO and other forms of digital content creation.

It gives a theoretical basis, practical follow-up information and provides foundational information to be shared widely.

What is accessibility?

Accessibility is about building products and services that everybody can use, including people with disabilities. Accessibility removes barriers and provides access.

Inclusive DesignDesign that has been adapted to include and consider everybody, including people with disabilities. and Universal DesignDesign that includes and considers everybody, including people with disabilities, from the start. go further than the removal of barriers.

For example: technically, an HTML range input (also known as a slider) has no barriers and can be used to enter a telephone number. However, the thought of using a range input for this is a ridiculous idea for many people. It is a very impractical way to enter a telephone number.
So even though a range input might be accessible in theory, it is also very impractical in reality. It is not inclusive and provides horrible usability for many.

Bad example: accessible telephone number input

Do not copy this example. Technically, this works. However, it is very unpleasant to use.

Please enter your telephone number:

Accessibility, and especially compliance, comes across as very binary: it either is or isn't and it either fails or complies. In practice accessibility is much more fluid. An experience can be improved without being fully compliant. The end goal is the removal of barriers, but removal of friction is also very valuable.

What is the impact of accessibility?

Accessibility impacts people with and without disabilities. The removal of barriers provides access to people with disabilities, but also has an impact beyond removing barriers.

People with disabilities

All statistics about people with disabilities share the same message: there are many people with disabilities. The exact numbers vary as factors like definitions and methods of registration vary.

1 in 4 adults have a disability.

European Council, Disability in the EU: facts and figures

An estimated 1.3 billion people – or 1 in 6 people worldwide – experience significant disability.

World Health Organization, Disability - Health inequity

More than 1 in 4 adults (28.7 percent) in the United States have some type of disability.

Centers for Disease Control and Prevention (CDC), Disability Impacts All of Us

Those numbers are especially concerning as we all become more disabled as we grow older, and more people become older in general.

51.3 % of persons with disabilities are employed

European Commission, European comparative data on Europe 2020 and persons with disabilities

1 in 5 leave school early

European Council, Disability in the EU: facts and figures

Adults with disabilities are more likely to have obesity, smoke, have heart disease, and have diabetes.

Centers for Disease Control and Prevention (CDC), Disability Impacts All of Us

The older you get, the more likely to have a disability

European Council, Disability in the EU: facts and figures

Disability is often split into three categories: permanent disability, temporary disability, and situational disability. These categories come from the inclusive toolkit by Microsoft. They help us understand that accessibility impacts people with a range of disabilities that we may not consider on our own.

Permanent disability

When we think about disabilities, we often think of this category. The quoted statistics are about this group of people. Accessibility removes barriers for people with permanent disabilities.

Permanent disabilities are lifelong. When you think of vision, this might be somebody who is blind. Somebody who is deaf or non-verbal could be in this category as well. These are the types of impairments that cannot be fixed, operated on, cured or reverted for whatever reason. They can be from birth but also acquired later in life from an illness, accident or other source.

The World Wide Web Consortium (W3C) has a series of stories about people with disabilities and how they use the web. They give an impression of what barriers people with disabilities can run into.

Temporary disability

A temporary disability is a different experience than a permanent disability. However, when we include people with permanent disabilities, we also improve access for those with temporary disabilities.

Temporary disabilities do not last forever. They can be from an illness, an injury due to an accident, or any other impairment that can be reverted. Thanks to medical technology, this category has grown. A broken arm used to be more of a permanent disability, and is mostly temporary now.

Situational disability

The third and last category is that of impairments caused by specific situations.

Imagine somebody at a concert. Concerts tend to be noisy, and it can be hard to hear. When they get a phone call, they cannot accept it. They cannot hear the other side of the call. This would be a situational disability: a disability caused by the situation.

Impact beyond disabilities

The impact of accessibility goes beyond people with disabilities.

People sharing the positive experience of inclusion.
A product or service can be bought or recommended by other people
Structured content is needed for assistive technologyAn umbrella term for technologies that support people (with disabilities). The term is broad and hard to scope. Examples include glasses, wheelchairs, walkers, crutches, prosthetic limbs, screen readers, braille displays, magnification software, custom keyboards and many more. but benefits all kinds of software and tools. This includes Search Engine Optimisation (SEO), translation software and AI agents.
The improved experience of inclusivity benefits all users: the curb cut effect.

The curb cut effect

The curb cut effect is a phenomenon where accessibility-focussed technology benefits more people than just those with disabilities. It is named after the curb cut as it is such an iconic example of this.

A curb cut (or dropped kerb) is a small ramp from a sidewalk or pavement down to a street. It is designed to physically remove a barrier, and improve accessibility.
The removal of this barrier is a necessity for people with wheelchairs and other mobility issues. However, it also benefits many other people like those with prams and strollers, people on bikes, carts and delivery vehicles, people with skates and many more.
This image by sketchplanations illustrates the concept.

Other examples of this phenomenon include:

closed captions
text enlargement on phones
game accessibility features in video games.

Solve for one, extend to many

Microsoft, Inclusive Design

If you design for the edges, you get the centre for free.

Rama Gheerawo, President of EIDD – Design for All Europe, quoted by Christopher Patnoe Head of Accessibility and Disability Inclusion at Google

Why is accessibility important?

At inklusivo, we believe people can have three main motivators when it comes to accessibility.

Accessibility is required to give everybody equal opportunities. Removing barriers for some people can improve the experience for others at the same time.
PractitionersSomeone who practices or is regularly engaged in skilful activity. In the context of accessibility: the people that do the production work like developers, designers, content writers, etc. can also be motivated because building an accessible experience is a skill.
The is also a group of extrinsic motivations that often overlap and intertwine.

1. Extrinsic motivations

There are multiple ways people can be extrinsically motivated. Extrinsic motivation can focus on positive and rewarding outcomes. It can also focus on negative and undesired consequences much like punishment. They are closely connected and often intertwined.

Market reach: An organisation that builds accessible products and services can reach a larger market than an organisation that excludes people. The Click-Away Pound Survey found that in the UK, 83% of users with access needs limit their shopping to sites they know are barrier-free.
Market share: Accessible experiences benefit from the curb-cut effect. They beat competition with a better user experience, better SEO and better compatibility with AI tools.
Legal and risk: Many organisations need to conform to laws like the European Accessibility Act (EAA) or Americans with Disabilities Act (ADA). Different areas of the world have different rules and regulations. They tend to align or overlap with the Web Content Accessibility Guidelines (WCAG)The Web Content Accessibility Guidelines (WCAG) are an international standard for digital accessibility. It is an established standard that is referenced in many laws, and is often implied when talking about accessibility.. Non-conformance can lead to fines and penalties, but also severe brand damage. For example, the US company Fashion Nova has settled an accessibility lawsuit for $5.15 million.
Marketing and branding: An organisation that excludes people with disabilities can suffer severe damage to their image. This can tie in with legal and risk. The brand damage of a lawsuit can even be higher than any related fines or penalties. On the other hand, an organisation that includes people with disabilities can position itself positively.
HR and staffing: Having a diverse staff that includes people with disabilities will increase the diversity of ideas and solutions. An organisation that is known as inclusive will have a more diverse staff. This is influenced by marketing and communication but also the accessibility of hiring, onboarding, internal tools and information. In other words, an inclusive experience for co-workers will lead to a diverse staff which will lead to diverse ideas and solutions.

2. Mastery

Mastery of one's craft can also be a motivator for accessibility. Any digital experience can be built accessible. Not everybody has the skills to do so. Having the skills to build accessible experiences can be a sign of somebody that has mastered their craft.

3. Ethics

A lot of people are intrinsically motivated for ethical reasons. An inaccessible experience excludes people. Exclusion of people with disabilities is a form of discrimination called ableism.Ableism is discrimination based on ability. It comes with stereotypes and negative assumptions about people with disabilities. For example, it is ableism when you do not consider a job application from a person with a disability because you assume they are less capable. The section What is the impact of accessibility? and its statistics are reason enough to build inclusive experiences.

Principles to apply

These foundational principles help turn good intentions into actions. Apply them to all experiences, products and services. Also apply them to anything related like manuals, documentation, support and sales channels.

1. Follow specifications

A big part of accessibility is nothing unusual. You don't have to build things in a specific way to work with "obscure assistive technology X". Follow specifications and standards, and the tooling that users have will do the rest.
As a builder, you meet people with disabilities halfway. The work you need to do for that consists of good practice and proven conventions. This makes things flexible and adjustable for users.

2. We are all different

"One size fits all" is cheap. It is efficient. It is easy.

However, people are not one size. We differ, in many ways. One size does not fit all. Assume people will want to customise, adjust, individualise, change, adapt... Assume that what you design does not fit. Assume your users do not want one thing.

Turn "one size fits all" around: "We are all different":

a. Follow specifications as already mentioned. This gives user the foundation to build and/or adapt their experience.
b. Provide multiple ways. For example, when you design a visual experience, offer the same but through another sense. Or as the EAA states: it must be made available via more than one sensory channel. But also, if you offer a nice digital experience with a website and an app: give people the option to call as well. If you offer a phone service, consider not everybody might be able to call, so also offer a website or mail. Always offer multiple ways to achieve something. Make sure all ways offer the same functionality and content. Give a podcast a transcript. Offer subtitles for your video. Do not try and list all options in your phone menu but assume people want something that is not in the menu. Systems are often designed to cater to the masses. Think of ways to support people outside of the masses. Go beyond the system.

3. Include people with disabilities

Hiring diverse people leads to diversity in your organisation. Diversity in your organisation leads to diverse thoughts and ideas. Diverse thoughts and ideas lead to inclusive products. Inclusive products enable hiring diverse people.

Nothing about us without us.

It is easier to hear the voices of people with disabilities when you include them in every step and on every level.

Diverse perspectives are also a great way to challenge any assumptions you might have. Including people with disabilities completes this set of principles.

Conclusion

Whether you are ethically motivated, want to improve your skills or your reasons are more extrinsic: follow specifications, assume differences and include people with disabilities.

Get this introduction as a powerpoint presentation deck (.pptx)

Frequently Asked Questions (FAQ) and common misconceptions

What does it mean when people ask "is this accessible?": The WCAGThe Web Content Accessibility Guidelines (WCAG) are an international standard for digital accessibility. It is an established standard that is referenced in many laws, and is often implied when talking about accessibility. are a very common standard. They are relevant for many legal situations. They are so relevant that "accessible" often equates to compliance with WCAG. For example: people often mean "does this comply with WCAG AA?" when they ask about accessibility. AA is the level of conformance often referred to in law.
What are examples of accessible experiences? Which organisations do it right?: A website that does well one day, might be horrible the next day. Websites change constantly. An organisation might have teams that build terrific things while other teams build terrible things. This can result in some pages being terrific and others being terrible. It can even result in differences in quality one the same page. That said, a website like w3.org should be a leading example.
What does it mean when people mention "limited screen reader support"?: It usually means corners were cut, specifications weren't followed, and mostly people with screen readers are excluded by it. Screen reader support is about following specifications. And when you follow them, screen readers benefit. There is nothing in WCAG that says "support screen readers". It is about code quality and a lot of it can be caught by linters and other code-checkers. Screen readers don't need specific coding.
Accessibility sounds like a lot of extra work!: It might not be as bad as you think:
A big part of accessibility is following specifications and best practices. This removes barriers for people with disabilities, but many more people benefit from this.

Conforming to WCAG is conforming to an international standard. The work you do is valuable for conforming in many countries. (And people benefit in many countries as well, as people and disabilities do not change when you cross a border.) This makes cross-border trading easier, and can open up new markets.

If compliance is your main reason, regulations like the EAA exempt small businesses (micro enterprises).

Where can I learn more?

This is a list of resources we refer to often. It is in no particular order.

Web Content Accessibility Guidelines (WCAG) 2.2: The official guideline as published by the W3C
How to Meet WCAG (Quick Reference): A quick reference that is must easier to browse and filter than the full publication of WCAG.
Solid Start: Our one-page introduction for improving the accessibility of products and services.
Using ARIA: The must-read when you consider using ARIA. It includes the very quotable first rule "If you can use a native HTML element (...) then do so."
Accessible Rich Internet Applications (WAI-ARIA) 1.3: The official specification as published by the W3C.
Accessible Rich Internet Applications (WAI-ARIA) 1.3 - Definition of Roles: The sub-section that specifies all roles.
Accessible Rich Internet Applications (WAI-ARIA) 1.3 - Definitions of States and Properties (all aria-* attributes): The sub-section that specifies all attributes.
ARIA Authoring Practices Guide (APG) - A collection of designs of custom-built widgets.
The European Accessibility Act (EAA)
Directive (EU) 2019/882: The directive behind the EAA.
EN 301 549 V3.2.1 (PDF): The European Standard “Accessibility requirements for ICT products and services”. The standard is there to align with both the EAA and the directive for public sector bodies (2016/2102).
The WebAIM Million: A yearly report on the accessibility of the top 1,000,000 home pages.
WebAIM Screen Reader User Survey #10: The very insightful 10th screen reader user survey by WebAIM.
Core Accessibility API Mappings 1.2: This document can help explain why screen readers announce what they announce.

Do you have feedback, improvements, additions or anything else you would like us to know? Reach out on the Access Club Discord server or contact us.

Personal note from the author

My name is Erik. Accessibility has drawn my attention for about a decade already. I have been interested in things like Web Design and usability for much longer. I have done work as a front-end developer, an accessibility consultant, a product owner of design systems, an organizer of meetups, and many things more. I do pretty much anything to improve to accessibility of what we build.
It feels weird and nearly impossible to summarise 10 years of experience. Still, it feels better than not sharing it. I did my best and will keep updating it with feedback and new insights. Please share any and all feedback through the Access Club Discord server or contact us.
This is a living document and my foundation for any work in the field of accessibility. When people ask me what accessibility is, I will share this page with them. When I produce a course, I will refer to this as the first chapter. I hope you do the same. 💚

Thanks

These fundamentals lean on the input of many. Some of that has been implicit. Thanks to all the organisations, projects, colleagues and friends. Your input has been valued greatly.
Explicit was the feedback of some people who were asked. In no particular order: Anneke Sinnema, Annelies Verhelst, Dean Birkett, Diede Gulpers, Eva Westerhoff, Tineke Timmerman, Rian Rietveld, Rowdy Rabouw, Wouter Lenssen, the people on the Access Club Discord server and many more.

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

QR codes and accessibility

QR codes and accessibility

A glossary of web accessibility terms

Blog

Blog

Live accessibility Q&A

Accessibility fundamentals

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

About

Contact

Live accessibility Q&A

Accessibility fundamentals

Table of Contents

What is accessibility?

Bad example: accessible telephone number input

What is the impact of accessibility?

People with disabilities

Permanent disability

Temporary disability

Situational disability

Impact beyond disabilities

The curb cut effect

Why is accessibility important?

1. Extrinsic motivations

2. Mastery

3. Ethics

Principles to apply

1. Follow specifications

2. We are all different

3. Include people with disabilities

Conclusion

Frequently Asked Questions (FAQ) and common misconceptions

Where can I learn more?

Personal note from the author

Thanks

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

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