Erik Kroes - Accessibility Consultant | Blog

Why I blog again

2019-06-12T00:00:00Z

It's been a while since I've spent some time and energy on my website. The content was outdated. The overall structure and design no longer offered what I needed from a website.

A self portrait of mine from more artistic times. I am using a view camera, obscuring my head with a blanket, but with the camera aimed at the viewer through a mirror.

That has changed now as I've redone the whole thing. My main reason the redo it was wanting to have a blog again. For me, there are at least three great reasons to have a blog.

In the past few years I've had the joy of learning a lot about accessibility. One of the things that I've always seen is that accessibility starts with awareness. It's hard to have accessibility in mind if you're not aware of what accessibility is. Once you are aware, you need the time and knowledge to do something with that awareness.

Now I'm not at liberty to give people time, but I can spread awareness, and I can share knowledge. And the best thing is, they're completely free and incredibly easy to share. So I'll be glad to share if it helps others. My experience is that it doesn't just help others. Whenever you share, there's always something that comes back from it.

Learn by building

Whenever I dive into learning something there are two possible motivators. It can be because I have a clear and practical goal I want to reach. I'll learn and use any technology that's needed to reach that goal. The other motivator is curiosity. When something grabs my attention and time permits, I can dive into the silliest of subjects.

A blog is a platform for both. I can have goals like: a WCAG 2.1 AAA compliant website with best practices for code and performance. At the same time it also gives me a good excuse to dive into details I usually won't encounter doing my day job. So far I've already learned about Webmentions, Microformats and how to order my CSS declarations.

Explaining clarifies

At the art academy we often talked about what we were doing. You talked to your teacher to explain what you were planning to do for an assignment. You talked to other students, asking each other what you're planning. Whenever you met other friends, family or whoever, you were always talking about your projects and plans. It could be that a project was stagnant for days or weeks. But each time I explained what I was doing, I understood more clearly what I was actually doing. Every time I talked, I had to think about what I was doing. About what the actual core thought or goal was. About how to communicate this to other people.

This process always improved whatever I was doing. It's kind of hard to explain, but by writing about it now, I can already explain it better. Whenever you consciously communicate about something, you have to re-evaluate what it is. Every re-evaluation is a chance for growth.

Onwards

The website is now ready (enough) for me to publish my thoughts on. I've got a big list of things I can still improve. Lots of topics I can dive into. The most important thing is that I have my platform now. Content will follow, if I'm not too hard on myself.

If you have any feedback on either the website or the content, please let me know. There is so much I can still learn, and I can't wait to find out.

Google, please be good

2019-09-06T00:00:00Z

Around one billion people in the world experience some form of disability. These people are also more likely to have other burdens. These include lower education, inadequate health care, lower wages and an increased cost of living.

The internet, in its core, is nondiscriminatory. Everybody can be equal when access is equal. That is where digital accessibility comes in. When you create a website, an app or any digital experience, you can include everybody equally.

The challenge of making something accessible is often not technical. The challenge is making people aware that they can contribute to accessibility and motivating them to do so. This is a challenge when you're trying to make an accessible product. The challenge is even bigger when you want an entire organisation to create accessible products. To have people world wide create accessible products, that's a near impossible challenge.

Give me a place to stand and with a lever I will move the whole world.
- Archimedes

Enter Google

There is no organisation that shapes our digital experience as much as Google does. They are responsible for the most used website, browser and mobile operating system. They have analytics, a voice assistant, their ad network, YouTube, AMP, Gmail and the list goes on.

Now imagine what good can be done for those one billion people by a company like Google. What would happen when an accessibility score would influence your ranking in their search result? What if there were accessibility requirements for publish your app in the Play store? No other company could make a difference like Google.

No one man should have all that power
- Kanye

Nobody could make a difference like a Director of Accessibility at Google. And that is exactly the job opening they have right now. I hope both the people hiring and applying are aware of what an opportunity this is. I hope they hire the most ambitious and empathic person they can find. I hope that person will chose to lead by example. I hope they will look beyond "don't be evil" and chose to be good.

An introduction to Web Monetization

2019-09-17T00:00:00Z

Web Monetization is a new proposed API standard. It makes websites able to request a stream of very small payments from a visitor. The best part, you can already use it and it's easy!

What is Web Monetization?

Web Monetization is a proposed API standard that allows websites to request a stream of very small payments from a user e.g. fractions of a cent.

This provides a framework for new revenue models for websites and web-based services, as an alternative to subscription services or advertising, while preserving the user's privacy.

In exchange for payments from the user, websites can provide the user with a "premium" experience such as exclusive content or by removing advertising or even the need to login to access content or services.

I can act like I know all the details, but that's a straight quote from the explainer. Web Monetization is a really simple alternative to advertising. A website has a single tag that points the browser of any visitor to a digital wallet. The visiting browser can then make a small payment to that wallet. Thereby making it possible for visitors to automatically pay for consuming content.

It sounds surprisingly simple. There are probably still tons of caveats like tons of money draining iframes, or clickbaity sites that I don't want my money to go. When it comes to money, people can get infinitely creative. But in its core, it sounds like an elegant solution.

Oh, and you can already use it!

How do I add Web Monetization to my website?

Even though it's a proposed standard, it's already being supported. Coil offers both a way to pay for content, and to receive payments for your content. I'll focus on explaining the "receive payments" part, as they explain the other one perfectly.

To add Web Monetization to your website through Coil, you first had to create an account. The call to action buttons are all over their website. Follow the process as described. I picked XRP instead of USD for receiving payments. I'm not planning on making any real money, so it might as well be a virtual coin.

Once you've gone through all the steps, you can visit the "Creator Settings" in your settings page. Here you can find your Payment Pointer. This is the wallet we mentioned earlier. Right below that is a short instruction and an actual HTML meta-tag. Mine looks like this:

All you have to do is add this to the section of the pages you want to monetize. The only reason it took me more than five minutes was my FTP server working against me. Now you're ready to be supported by your 3 loyal visitors. To show your appreciation, you can change the experience of paying users. You can hide advertisements for example.

What's next?

I'm really looking forward to see where this standard is going. There are grants coming for developers and creators who support and promote Web Monetization. That should shake things up a little. The least we can do is show some support. For example by using Puma Browser or adding a Coil extension to Google Chrome or Mozilla Firefox.

I'm thrilled to be part of this. We're giving a hundred million dollars to content creators (e.g., you), to kickstart a new, decent, private and respectful way for people to be paid on the web, by their fans. https://t.co/nb3mAifGBJ
— Bruce Lawson (@brucel) September 16, 2019

Personal update

2020-02-26T00:00:00Z

I think I'm allowed at least one personal message these days. There's no thread or solid reasoning in this. My mind is still mushy so there should be typo's, but it's the mind I have. 🎉 But to me it's all about gratitude and privilege.

How it started

So, first some steps back. To how it all started. I had brain surgery in 2002 and 2004. In 2002 they operated to remove a pilocytic astrocytoma. That's a benign grade 1 brain tumor, in my cerebellum, that somehow gave me no complaints. Another weird story, but they discovered it accidentally.
From 2002 and onwards I had checkup MRI's. There was still/again something visible in 2004, so they went in another time. The surgery gave me complaints till this day. By now I've learned that the official term I should use is non aqcuired briain injury. Aka, it didn't start out like this.
I've had issues with balance, nausea (lots of this), oversight, planning, energy... basically all the complaints you usually have before you find a tumor. It's why I'm used to working 3 days a week. But all this started in 2004. And I still have the MRI's.

Checkups

The MRI's always felt like checkups. Something we crossed of a list. The last one felt just like that, except it wasn't. The previous one was 4 years ago, and there was something visible. Our expectance was clean results each time.
The MRI scan was on a Thursday. We spoke on Monday. They could not tell us anthing yet. At that point it could've been anything in my head. Including all kinds of cancer that you discuss as a state of a few years. Obviously, my head went racing after that. I'm born in 1984. I'm far too young to have a lifespan, or some clock ticking in my head. I have a 3 year old daughter and a wife. That night was terror.

The day after they had discussed the image. It was "most likely the same thing". Which means surgical removal, and no chemo, radiation or anything afterwards. Big difference, but still a weird rollercoaster. We expected nothing, and now it was "only brain surgery". Yes, people do think like that.

Waiting

I was placed on a waiting list. I came in for admittance on a Tuesday. I would be called in around 11:30 in the morning, for surgery at 12:00. Except, there was no room in Intensive Care or Recovery afterwards. I was waiting for my wife to either get brain surgery, or be placed back on a weeks-long list. And we didnt know anything.
Fortunately (?) I ended up getting brain surgery. And this is where I'm never thankful enough. My wife was there first thing and she was there every day in the hospital. She cared for me, looked after my agenda, and I only had to focus on recovery (get moving!). I felt much better than last time and even had more jokes on the first evening than last time (valuable metric).

It's no been two weeks since surgery. I've had the amazing news that I once again have a stage 1 tumor. This means they removed everything, and I should be done now. I can't say that enough. I was so very lucky. Everybody there had worse complaints. All my issues feel like they'll be no issue in due time. I've got problems with my sight (including nystachms) but I don't mind a computer at 150%. My balance isn't there yet, but it's improving each day. I asumme a ton of typo's, but they get less and less. And I am actually typing this. I feel like the sharpest tool in the shed. Brain surgery is no joke, but it really feels like I had it easy. My wife took care of me. My daughter had family take care of her. The hospital was amazing. I've seen lots of talk about bay area salary, but I just got my head cut open, and I probably won't spend more than my deducitble. I even got to build LEGO sets as part of my recovery. I can take my time, and just pick up my life where I left it. I feel so very priviliged. I did spend at least one week extra in the hospital, because my wound kept leaking. I really really did not like that. I had to lay still and do nothing. Which was really hard when I already went home before that. But all I could think about was privilege. I had my wife. I had family. In the end, it felt like I didn't have to do much but be the best patient I could be.

So where is this post heading?

I guess this is a big thank you. To the hospital and staff, to my wife, to my family and to more priviliged position. I can return back to my life. Maybe even do more than before (I'd love to). I'm not sure what the most logical route is, but people can always donate. I was part of the Neuro Oncology Department D3 Oost. Not sure if they can be mentioned specifically. I'll see what I can do for the hospital and staff in the near future. If they take care of other people, like they took care of easy me, then they're doing amazing.
I'll be patiently rebuild whatever I had in the next weeks. My wife is amazing. And so is my daughter, who does not want to leave me alone. I feel rich with opportunities. I'm somewhere between Zen and Arrogant from having too much time on my hands. So I think I'll be able to do anything, and take any role or position in the near future. So if there's any bay area remote money, please do let me know. But I feel like I should be fine either way.
Please take care of people whenever you can. Health is not a given. All fundaments are temporary. Share when you can. I know I will. Let me know if there's anything I can do.

Again, I'm so thankful. I can walk away from all this. I can enjoy my daughter and family. I can rebuild a life, and keep contributing. It's never a given and I'm very lucky.

The Guide to Accessible Web Components

2020-03-10T00:00:00Z

Web Components are a newly supported standard. They're a great match for Design Systems because they're futureproof and work with any framework. Building proper UI Web Components can be quite a task though, especially if you want them to be accessible. Here are some pointers on what to look out for.

Throughout this article I'll use Lion a few times as an example. Lion is a collection of white label UI Web Components. There's more information about Lion in the conclusion.

What are Web Components?

Web Components are a set of standards:

Custom Elements: A way to create your own HTML elements
ES Modules: Self-contained modules of JavaScript code that can be reused and extended
HTML Templates: Reusable fragments of DOM
Shadow DOM: Encapsulation of DOM

Together these standards enable "Reusable extendable encapsulated self-contained components for the web". That's quite a mouthful, but not very clear.

In practice, this means you can create your own HTML elements. These elements have their own bit of encapsulated DOM. In this, and many web-related cases, DOM stands for Document Object Model. The DOM is how we see an HTML or XML document. MDN states "The DOM represents the document as nodes and objects." MDN has a rather good explanation.
It means the HTML element you make can't be touched or influenced by whatever is outside of the element. They can't be accidentally styled, and they won't mess with your global styles either. And because it's an ES Module, the whole element can be distributed and extended. All these aspects together make up a Web Component.
ES Module stands for EcmaScript Module. It's how JavaScript works with modules and a standard that's supported by all modern browsers. 🎉

A practical example would be a Google Maps Web Component. This Web Component shows a full interactive map on your page with only a few lines of code. You would have to import some JavaScript on your page that defines the component:

After that, you can use your custom element anywhere on the page.

Notice how the element name has a dash? That's part of the Custom Elements specification and makes it easier for the browser to recognize them.

A not so practical example would be a spacer-gif Web Component. (A spacer-gif is an old an redundant technique that does not need a remake.)

A Lion example could be lion-switch.

And all that goodness is based on widely supported web standards.

What is shadow DOM, and light DOM?

"Indeed, that sounds pretty good so far, but what's the catch?"

As the British will soon discover, there are some downsides to isolating yourself. Let's say you make a card component. The interface for using it (what you see in your editor or browser) could look like this:

  This is the card content

The component, when inspected in the browser, could look like this:

  
    #shadow-root (open)
      
        
          Presenting the card content:
        
        
          
            <#text>↴
          
        
      

    This is the card content

A whole chunk of DOM ("The DOM represents the document as nodes and objects." Remember from before?) is rendered by the component and put into the shadow-root section. Inside the it refers to the content we put into the element in the first place. All the DOM that is added, is shadow DOM. All the other "normal" DOM, is what we call light DOM. It's the part that's always visible.
As the shadow DOM is completely encapsulated and isolated, it is also completely disconnected. It's almost like it's a completely different document like an iframe. Thankfully, keyboard navigation does work through Shadow DOM boundaries. Which means you can in and out of Shadow DOM.

This becomes a challenge when you want to point a label to an input to create an explicit relationship. In plain HTML, this would be:

  Label text

When one of both (the label or the input) is in the shadow DOM, they're in a completely different context. This makes it impossible to refer to eachother.
This same dillema also goes for WAI-ARIA attributes like aria-labelledby, aria-describedby and other that reference an ID. You need either both elements in the shadow DOM, or both of them in the light DOM. Light DOM does not mean that they both have to be in the same slot though. Light DOM is basically all the DOM that isn't shadow DOM.

In the lion-input we let the developer declare a label in the label slot. This label ends up in the light DOM.


  Label text

The component places an input in a slot="input", help text in slot="help-text" and feedback in slot="feedback". This means the input can be connected to the label, but also that we can use aria-describedby to connect the input to help text like instructions and feedback like error messages.

Extending elements

As it stands right now, it is only possible to create a Web Component by extending a generic HTML element (HTMLElement) or another Web Component (which should be somewhere deep down, also an extension of HTMLElement).

For accessibility, it could have been a big win if we could extend any element. Imagine you could, for example, extend a native button (HTMLButtonElement). You would inherit all its behaviour and it's semantics, and you would only add on to that. You'd have a solid fundament upon which you could build.

The specification exists but Safari has stated to not support this feature. Part of the beauty of Web Components is that it's a supported standard. So even though there is a Polyfill for Safari, it creates a path with future uncertainty.

Accessible UI Components

The most popular usecase for Web Components is probably that of creating custom user interface controls. As we can't extend any native elements, we often end up with either wrapping a native element, or recreating its behaviour by ourselves. Wrapping is often the easiest and most solid solution. Recreating is basically the same as taking a

as a starting point.
There are so many aspects that come together in a single components, that it is really easy to overlook a feature or behaviour. And when you forget or fail to implement something, you end up creating something that's lacking compared to a native element. That's probably the exact opposite of what you're trying to achieve.

Here is an overview of aspects that need special attention when creating an accessible user interface control. These points are not specific to Web Components. They are just as relevent for React, Vue, Svelte or any other framework.

Focusable

If your custom control is interactive, make sure it is keyboard focusable. For simple controls with a single interactive element, this means adding tabindex='0' to your control. For more complex controls you might need to implement a roving tabindex or use aria-activedescendant.

Keyboard interaction

Users should be able to use your interactive control with a keyboard. For many design patterns, suggested keyboard interactions can be found in the WAI ARIA Authoring Practices.

Visible states

Interactive controls have several states like focus, hover and active. These should all be clearly visible, and, preferably, each have their own distinctive styling.

Functional states and properties

An interactive control can have functional states as well. For example, a disclosure widget (or expandable, accordion, expando, ...) can be open or closed. This state needs to be not just visual, but communicated in code as well. This can be done by toggling aria-expanded on your control.
The same goes for properties like aria-multiline. They communicate properties that might be implicit in native elements, that have to be added manually for assistive technology when you're building custom controls. WAI-ARIA has many states and properties to aid in this.

Semantics

Native HTML elements have a semantic meaning and are mapped to WAI-ARIA roles. Their semantics are implicit and always there.
A custom element starts out with no role at all, but you can assign one explicitly. WAI-ARIA offers a wide range of roles that should cover all use cases. WAI ARIA is more explicit than native semantics though. It's more bolt-on than built-in.
You might notice when using Windows High Contrast Mode, a special tool for Windows. It does not care for your ARIA attributes.

Accessible name

Interactive controls must have a name for them to be identified by. For example, a

Semantics, what does it mean?

2021-01-19T00:00:00Z

When people talk about the quality of HTML code, it is often about semantics. But what are semantics? What is semantic HTML, and why should you care about it?

What is Semantic HTML?

Semantics is communicating your intention through your chosen HTML. This does not guarantee the correct outcome, but if you communicate a different intention than the outcome, then it is not correct anyway.
A well-known HTML tag is, for example, the

. This tag is often used for the most important heading (heading 1) on a page.
`Semantics, what does it mean?`

The tag or element communicates the intention: this is the main heading, this is what the page is about. If (for example due to an error in the CMS) there is an entire article in a

then the result does not match the intention.
In the same way, you can create a link () that goes nowhere, or a button (

I made this website with HTML

2021-03-20T00:00:00Z

This website is 100% semantic. There are no

s or s. Every element has been chosen to play a role, because every element has a role.

I even tried to follow the HTML Document Outline. Still some possible improvement there, but at least that's not actively used right now. (I'm still a fan of the idea though. One of very few probably.)

Why only semantic elements?

You might have seen Heydon's website. It only works when you have JavaScript disabled. I think this is great as a statement. I see Heydon as a natural artist whose statements make people think about things. The value is in the message, and not in following the example. I always appreciate these kind of statements, but I'm also too practical to come up with them myself. So my addition (not an alternative) is a website where every element has semantic value.

If you're not familiar with semantics, or what they contribute, you could start with my blog "Semantics, what does it mean?".

In the current landscape of websites where frameworks like React are king,

s and s rule the land. They're like corn starch. A nothing that can turn into anything, but won't bring anything to the table by itself.

For building websites, these elements add nothing to the content or the semantic value of the content. They're overused. Code is often cleaner when these elements are limited. This improves readability. This improves maintainability. There are more reasons than fit right here, but focus on

Why HTML first?

The startpoint for my website was the content. I had content (to create) and wanted a place to put it. I want to communicate and share.

So I started with thinking about the structure of my content. How do I make logical divisions in my content? In the end I have several pages with their own content and sections. The pages provide context like a title and a URL. Within the pages you can also provide context with (there it is again) the semantics of HTML.

All my content went into a HTML-structure and at this point I was practically done. I had a working website, with separate pages, with all content I wanted in there. My content in the structure that I wanted, and usable by everybody. After that I started changing things with CSS and the funny thing is, CSS had only one goal for me: CSS is there for the visual aspect. I added CSS for the people that saw my content. It didn't improve or change my content in any way. If you're working on the visuals of a website and want to change your HTML structure, think if you really want different HTML or just different visuals.

I liked the idea of CSS follow HTML. The HTML structure was there for the content, not for the visual appeal.

Why no JavaScript?

With the content done, the structure done and the styling done, I had only one step left. I was free to add JavaScript!

I was also free to add no JavaScript. Everything was perfect already. JavaScript opens the door to increased loading times, and (for me) mostly more complexity building. This website has no JavaScript, so no build, no NPM-modules, no many things. Most of the content is in Markdown files and can be edited through a WYSIWYG-editor. I'm typing this on forestry.io and it's a great experience.

No JavaScript for me, is the easiest learning curve for keeping this website up and no overhead for tooling. If I forget about this website for a year and want to add content, I only need to open an editor in the browser. If I want to move to a different system, all my content is in Markdown files already.

Being flexible and lightweight is a luxury. The less you have, the less you have to worry about.

What else isn't there?

There are no media queries or breakpoints. Which means no duplicate CSS and not being dependant on devices.

There are no CSS classes. (And the only IDs are for use with aria-labelledby.) When you have a clear HTML structure (and it's not too complicated, like on a personal website), it's easy to target elements. It's also fairly robust as nobody will be touching my HTML but me. I understand this does not work for your corporate project X because reasons, but just look at my code once. See how clean it is?

There are no comments. And I don't mean in the code, but below blogs. That's a whole different decision. I've got a list of like 30 things I still want to improve. But consider this an MVP (Minimum Viable Product). My goal was to have something minimal that I can iterate on, and I really really wanted a place to play, write and experiment. Expression is key.

Other notes

The font is Atkinson Hyperlegible. It's made to be readable.
There's no skiplink. I prefer a minimal navigation.
My list of improvements includes:
- Comments/webmentions
- A portfolio
- Microformats
- A sitemap
- A photopage that sends posts to Twitter
- A 404 page
- More content
A lot of this code was inspired by Max Böck. His code is a great base for building a website with Eleventy (like I did).
The code of this website is on GitHub. I hope you find it useful and have questions.
This process was very much inspired by Jeremy Keith and his book Resilient web design. Read it. It's short (jay) and much more eloquent than my scribbles here.

Your website is history

2021-04-05T00:00:00Z

Everything you put on your website is old. Every website is an archive. The web is a collective history.

A tweet by Stephen Hay got me thinking about this subject. He pointed to a concept called a now page. The idea of a dedicated page on your website "that tells you what this person is focused on at this point in their life". "Think of what you’d tell a friend you hadn’t seen in a year."

When Dave Rupert posted his Vibe Check shortly after, it felt like further pressing the point. Webites tend to be about looking back.

"Where have you been?"
"What have you done?"
"What have you achieved?"
"What have you built?"

For somebody who likes to look forward, that feels really limited. My past shaped me, but it's not the entire story. So I'm thinking about creating a now page. There's a programmer inside me and the first question that pops up is, how can I structure this? How can I prevent repeating myself?

Don't Repeat Yourself

Making me write something again and again is a recipe for failure. I respect all people who write newsletters because it sounds like a terrible chore to me. The same goes to all people who create patreon-content on a schedule. I don't know how your brain works, but I assume mine doesn't work the same.

My website is currently static. It's not pulling in any information when you visit it. It could pull in information when publishing. Some things that I want to try:

Most listened music from last.fm
Recently read or currently reading
Current LinkedIn headline
Recent Twitter messages
Maybe steps, weight or other health stats

The downside of these things is that they're mostly focussed on consumption. I don't want to be defined by what I consume. Something like solar panel power output would already be more interesting if you'd ask me. I'd like to add more focus on production like recent pictures, writing or projects.

To now and beyond?

But even if I post about my life every month or so. It feels like a step is missing. Past and present are not complete without the future. Before I start to build a /now/, I'm thinking of the next step.

How can a website reflect a future?
How do you present something digitally that hasn't even happened yet?

The image in my head currently is a sort of kanban-board with goals and how I'm progressing on them.

Working out in the open is fun. What I also like about this, is that I'd create a real log of my life. It touches the subject of lifelogging, and would turn this website into a documentary project for me.

The value of less

2021-07-08T00:00:00Z

In 2019 we started planning for a new house. I started sketching layouts because I didn't know what our needs were. It's kinda hard discussing budget with construction companies if you have no idea what you want to ask from them.

Drawing houses was fun. With every iteration I felt like getting closer to an ideal living space. With every iteration, it's also really easy to add something. A bit of space here, another room there... when you're not paying (yet), it's easy to dream big.

What I discovered is that I didn't want big. I went for as little space as we needed. Every bit of space you add to a sketch doesn't just add construction costs (which is plenty already). It also means you have to heat (or cool) it. You need to keep an eye on it, and maintain it when necessary. When it's broken, you probably want to fix it.

With everything you add and gain in your life, you become bigger and less flexible. You gain responsibilities and have more to lose. It's like the real life version of technical debt.

It made me realize that keeping my house as small as possible, would make me the happiest. Upfront costs are a front.

It also gave me a new mindset to think about choices. Let's say you want sustainable energy and can't pick between wind, sun or nuclear. Now I'm no specialist on sustainable energy. I don't know what the long term impact is. I'm not even sure if I can be sure. What I do know is that whatever I pick, I always have control over one factor that improve sustainability. I can consume less energy. That's always better.

Organic food. Is it better for the person consuming? Is it better for the planet? I don't have the energy to find out exactly what's the smartest choice. There are so many factors. I do know one thing. It's always good to eat less. To waste less. That's one thing that lessens my impact on earth's resources for sure.

I believe this mindset transfers to many choices and technology is not excluded. I also think it aligns with what Jeremy Keith writes about how he works, in his book Resilient web Design:

Make that functionality available using the simplest possible technology.

We might not always be able to make the best choices from a set of options. But we can always aim for less. Stay agile and flexible.

A photographer’s view on alt text

2021-08-04T00:00:00Z

Images are visual communication. Consider what you’re trying to communicate before you do.

What is alt text?

When I say alt text I’m usually talking about the alt-attribute for the img-element in HTML. But most of what I say goes for other text alternatives as well. So maybe the question should be, what is a text alternative?

An image says more than a thousand words. But if you can’t see an image, well, then it doesn’t say much does it? A way to compensate for this is to add a text alternative; a bit of text that serves the same purpose as the image.

What’s the purpose of the image?

This is the big question if you’d ask me. Wether you add an image to an article you’re writing, or you’re adding it as an icon to a button, you can’t avoid this question. What is the purpose? Why are you adding this image? What are you trying to communicate?

In the end, an image is "just" a way of getting something across. When you write, you pick certain words. You write your sentences in a certain way. You can be aware of how you’re communicating and what you’re bringing across. An image isn’t much different in my experience.

When you pick an image, ask yourself the same questions. What am I trying to communicate? (Notice this question is very much focussed on the person creating the content and not on what a user wants.)

What does that mean in practice?

Let’s take this image as an example. What does it denote? And I’m picking this word because it is one I picked up during my study in photography. The literal meaning of something is its denotation. In this case it could be something like the pretty generic alt text I added in the code: "President Obama speaking from behind a pedestal". The denotation is also right up the alley of image recognition by artifical intelligence (AI). You literally describe what’s in the image. Although you could easily go for an even more literal description here like: "A man in a suit behind a pedestal".

Stating it’s President Obama is already more of a connotation. It’s an interpretation of what we see. It’s a cultural addition. Other connotations could include mentioning it’s the first black president, that it’s a former president or that he’s talking about Donald Trump here.

And this is where the purpose of the image plays a role. If you’re writing an article on the achievements of black people in the USA, you might add Obama as the first black president. If you’re writing a course on public speaking, you might add Obama to illustrate that public speaking is very important for presidents. If the image is to supplement information about pedestals, then you might want to focus on highlighting details on the pedestal in the picture. It all about the purpose. Why are you adding the image?

The denotation has value but the connotation is often why we add an image. When somebody adds a description of an image into the file (like discussed in this Twitter thread), it might be enough to derive a connotation from it. But to really get the message across, write your own text alternative.

Some more tips

Don’t include that it’s an image. Or a picture, a graphic, a visual, etc. That only adds noise as it’s already clear from the context.
Write out text.
Don’t stylize text. Italic and bold text don’t change the message (and might not even be communicated). The same goes for anything beyond basic punctuation.
"Null" the alt of a decorative image. In HTML, if an image is decorative, add an empty alt like or . And I do mean empty. No spaces or other text like "image" (I’m looking at you Twitter 👀).

Why I care

For the past few years, I’ve been working as a specialist in digital accessibility and inclusive design. In this role I work with WCAG, and the addition of text alternatives is pretty much the first thing I check in an audit. Through this role, I’ve formed an opinion on text alternatives.

Before this job, I was a photographer. I had 5 years of formal education in this direction. Visual communication is awesome and I wish the theory had stuck with me even more.

Concluding

Studying photography has taught me that it’s all "just" visual communication. Wether it’s text or imagery. Think about the message you’re trying to communicate, and shape your communication accordingly.

Resources

A closer look: "A family evacuated from Afghanistan arrives at Dulles"

2021-08-29T00:00:00Z

I shared an image of Afghan refugees too haphazardly. Let's have a second look.

First impression

On Twitter I "quote tweeted" this image with the text "They couldn't get the magic carpet in the background?" That did not get across what I intended to say. At all.

What stood out for me is that the image seemed over the top, filled with stereotypes and maybe even a caricature of the situation.

I tend to enjoy more subtle pictures. This one was not at all subtle to me.

Traditional garb (I assume)
A jorden/just do it shirt
A peace sign
Pants covered with branding and/or strongly cultural texts
Bags of Dorito's

And there's probably a lot more I didn't even pick up. To me, those cliches and stereotypes feel like they simplified a situation to such levels, it became insulting. So in the "spur-of-the-moment" I tried to imagine what could make the image even worse and came up with a magic carpet.

I tried to amplify what I "read" in this image. Without context, that's a strange addition to a sensitive photo.

On second thought

Looking more closely at the image, and putting things into perspective, I'd like to add a bit more reflection. This picture is shown in media because it "works". In media there's no room for subtle, in-depth or lengthy. That does not align with my personal preferences, but that seems to be the way these things work currently.

What the picture does express strongly, and what I hope there will be attention for, is the assumed extreme cultural differences between where these people come from, and where they just have arrived.

The world is full of chasms. East and west. Rich and poor. Beliefs. Technoliteracy. There are so many that it's overwhelming. I'm a big proponent of being inclusive and giving everybody equal opportunities. These days that seems hard to imagine. I feel like chasms only get larger and everything we do divides us further.

It's depressing. They are strong feelings for me which, looking back, might be a reason for my confusing reaction to it.

Color and contrast, what does it mean?

2021-08-31T00:00:00Z

The color contrast ratios mentioned in WCAG can give you an insight in how usable your color palette is. How that works isn't very transparent. Learn more about how the color contrast ratio is determined, and what that means for you (and your palette).

How it used to be

When I started auditing websites and designs, my life was still simple.

I'd grab a color picker tool like the Colour Contrast Analyser.
For pieces of text, I'd pick the background color.
And separately I'd pick the foreground color.
The tool would spit out a number for me; the contrast ratio.
I'd apply WCAG Succes Criterion 1.4.3: Contrast (Minimum). In short, if the ratio is below 3.0:1, it would lack contrast. If it's above 4.5:1, it would be fine. If it's inbetween, I'd have to check the text size. Large text (at least 19px and bold, or at least 24px) would still pass. Fail for anything else. This all assuming an audit at level AA.

Problably no big surprises for many people reading this. A small recap to make sure. I use a tool to measure the contrast between text and its background. WCAG gives us a ratio as a minimum requirement. Large text gets a bit of slack.

I didn't question the numbers, and the numbers didn't question me. Until I did.

The fabric store

This all changed because I ran an online fabric store with my wife. An online store needs a website. We had one, but it was WordPress, and WooCommerce, and a theme, and a child theme, lots of extensions, and two versions of bootstrap at the same time. Let's say there was room for improvement in how things were built.

So I went for an adequete amount of exaggeration and thought, why not start with the basics? Why not start with... an accessible color palette?

And that's when things got interesting. I always learn things when I put myself in the shoes of people I usually communicate with. In this case, I dove into something designers usually do. And (spoiler) it's not easy to make such a color palette!

Color, it's pretty complicated

Studying photography has taught me color is not an easy subject. You quickly touch on subjects like:

How do eyes work?
How does the brain interpret what it sees?
How do we display color?

It's a colorful rabbit hole, but still a rabbit hole.

Color models

Red, Green and Blue

If you're reading this, I'm assuming you know something about computers. On computers we traditionally define colors with Red, Green and Blue. Why? Because displays work with tiny red, green and blue lights. And together they can be any (sort of) color. An RGB-notation can be used for this.

In CSS there is a scale of 0 to 255 for color values. 255, 0, 0 means all the red, no green and no blue. This results in red. A harsh blue would be 0, 0, 255. Orange is full red and half green: 255, 127, 0. White is 255, 255, 255. Black is 0, 0, 0. The value is from 0 to 255 because thats 256 and 2 to the power of 8 is 256 and a byte and.. before you know it I start ranting about color again.

But nevermind. WCAG works differently.

Hue, Saturation and Lightness

There's also HSL (instead of RGB). It works with Hue, Saturation and Lightness. You might've seen (haha) it before. Hue is like having all tints in a circle. It starts with 0 (degrees) for red. Rotate to 30 and you get orange. Rotate to 60 for yellow. 120 is green. 240 is blue. 360 or 0 (full circle) is red again. Feels much more intuitive to me!

Saturation is how saturated or full a color is. 100 (percent) for full color and 0 for none. The L is for Lightness. How light an image is with 100 (percent) being white and 0 being black.

That sounds much more understandable and readable than RGB. It's almost usable! But of course, it's not. Making things easy would be... too easy? Compare the two colors in this image.

It's a blue (240, 100, 50 in HSL) and a yellow (60, 100, 50) in HSL. The only difference is the hue. But to our eyes and in our perception, the blue is much darker than the yellow.

To put it in further perspective. These are three red squares. The first and brightest is 0, 100, 68. It has a contrast ratio of 3.0:1 on white. The second is 0, 100, 47 and a ratio of 4.5:1. The third is 0, 100, 36 and has a ratio of 7.0:1. The ratios were picked because they're practical in a WCAG-context. Don't read too much into them.

Now what happens if we make a grid with the same saturation, these three luminosities but different hues?

We get red, yellow, green, cyan, blue and magenta. They're evenly spaced on the hue-scale. They are not, however, evenly scaled in contrast. Where red a nice 3.0, 4.5 and 7.0, yellow is 1.1, 1.2 and 2.1. Much lower numbers! So the L-value is the same, but the contrast isn't. Blue is much like the opposite of yellow in this case with contrasts of 4.8, 9.3 and 12.4. Where the darkest yellow is not contrasty enough (according to WCAG) for large text (it's less than 3.0), the lightest blue is dark enough (more than 4.5) for small text even!

Check out all the contrast ratios in this table.

Red	Yellow	Green	Cyan	Blue	Magenta
3.0	1.1	1.3	1.2	4.8	2.6
4.5	1.2	1.6	1.4	9.3	3.5
7.0	2.1	2.7	2.5	12.4	5.6

Is that all?

Maybe you know some other models as well. There's RGBA and HSLA, which include opacity. There's HSB (Hue, Saturation and Brightness) used by tools like photoshop. There's CMYK (Cyan, Magenta, Yellow and Key/blacK) for print. Plenty of options!

And I'm not even going into Color Spaces yet here. I told you color can get complicated!

WCAG?

Yeah sorry. WCAG uses none of those really. Contrast in WCAG is based on ITU-R Recommendation BT.709. What? ITU-R Recommendation BT.709. That's not very clear.

ITU-R Recommendation BT.709, more commonly known by the abbreviations Rec. 709 or BT.709, standardizes the format of high-definition television, having 16:9 (widescreen) aspect ratio. The first edition of the standard was approved in 1990.

That doesn't help much either probably. Sorry about that. Some things that stand out:

It's a television standard (of course, why not?)
It has the same color coverage as sRGB (a much used color space, relevant to computer screens)
It has a component called Luma (component like R in RGB or H in HSL)
It's a way to measure brightness in sRGB that takes the human eye in account

Trying to get back to why all of this is relevant. You don't measure RGB values when you use a color contrast tool. What's relevant in the end is the Luma-component. This component can be calculated from RGB (sRGB usually). The contrast is about 72% based on green (because our eyes are generally sensitive to green), 21% based on red and about 7% based on blue. Your eyes don't care much about blue.

We have Luma!

Now we have this value, it's used to calculate the contrast. As you may have noticed in contrast tools, the value varies from 1:1 to 21:1. It's never below 1 or above 21. That's due to the formula WCAG uses. It's a practical choice as far as I know.

So if black is 1, then white is 21. White is 21 times as bright as black in this system. And black is 21 times as dark as white. The implication here, that was the big eye-opener for me, is that it's a ratio with a clearly defined range.

If black is 1, and a color X has a ratio of 3.0:1 on black.. then X has a ratio of (21/3=7) 7.0:1 on white.

Trying to phrase this in multiple ways because it took me a bit for the coin to drop. If black is 1, X is 3, and white is 21. Then white/X (21/3) is 7.

If you have a color Y that's 4.5:1 on black, then it's also (21/4.5=4.67) 4.67:1 on white.

What does that mean for color palettes?

If you are aiming for a minimum contrast of 3.0:1 between shades, then there can be only 3. You've got black at 1. Your shade at (at least) 3.0:1. And the next shade would be at (at least) 9.0:1. Because 9.0 has a contrast of 3.0:1 to 3.0. But, you can't triple 9.0 once again. Then you'd get 27. And 27 is more than 21. You can't create something brighter than white.

The same goes when you want a minimum of 4.5:1. You can do 1, 4.5 and 20.25 (4.5 times 4.5) but multiply it more and you go beyond 21. Not an option.

If you're going for a higher contrast like 7.0:1 (relevant for text when looking at WCAG AAA), you can't even fit 3 shades. You can do 1, 7 but 7 times 7 is way too high.

What's the practical impact on palettes?

Everybody seems to be working on dark mode these days. It's useful to know that if you want to pick one text color that works on both black and white, you don't have many options. Ideally you pick something with a ratio between 4.5:1 and 4.67:1. There's not a lot of space. It's good to be aware of how WCAG contrast influences your palette.

Conclusion

Math is hard. The best way to understand all written here is probably by trying some tools. One of my favorites is Contrast Grid by Eightshapes. You can insert an entire palette and see what color combinations offer acceptable contrasts. You can use this pretty usable palette by me as a starting point. It aims to offers many usable color combinations (but feel more than free to aim higher).

Another tool I enjoy is Leonardo. It's a tool to generate great palettes with lots of control over contrast and other options. Probably a good step before trying Contrast Grid.

And yes, WCAG 3 will quite likely provide a new way to calculate contrast. That's great news but we're all working with WCAG 2 for now.

Let me know if my ranting has helped you, and if you have favorite tools of your own!

Oh, and we sold the fabric store. I never ended up making a whole Design System for our little shop. Probably better that way.

Resources

Inclusion beats optimization

2022-08-18T00:00:00Z

When you're building something and you're moving fast, make sure to look back every now and then. Check if everybody is on board before moving further. Make sure to include people every step of the way. Accessibility has priority over other issues

You start using a new product (hurray). You encounter an accessibility issue (meh). You can report it in a repository (hurray). A helpful maintainer labels it (hurray). They tag it as a "feature request" or "enhancement" (ohno). You have to convince them it's an actual bug (meh).

It sounds like a terrible customer journey map, but this often happens with accessibility issues. People don't recognize them as bugs.

Issues and open source

Open source is great. People make something. They share not just the result, but also the work behind it (the open source code). Often this is shared in an open place (a repository). If you want something changed, you can work on the code yourself (hopefully). Another option is to leave a message for the maintainer or another friendly person, and they might help you out. We call these messages issues, and they're often labelled to keep things a bit organised (and not too chaotic).

Feature requests and enhancements

Issues in the category with the least rush are often called Feature requests or Enhancements. It's when you've got an idea for something the software doesn't do yet. Sometimes it's a new functionality. Sometimes it makes it more fun or efficient to use. It's not like you can't use it at all, but it could be better. It could be enhanced.

Talking as a former product owner: these issues don't have the highest priority. They're more nice-to-haves than emergencies. You can put them on the todo-list (the backlog) but you'll get to them in due time. It's even better to not rush into creating too many new features. Often new features also introduce more bugs.

Bugs

Bugs are a different category of issues. When something is broken or flawed, then it's a bug. A product might crash. It might be uninstallable. Unlike feature requests or enhancements, this type of issues are unintentional mistakes. The product is broken and unfinished. Bugs need to be fixed and have the highest priority.

Accessibility issues

In large organisations, a lot of focus can be put on enhancements. The customer needs to stay on our pages longer! More feedback forms need to be filled! We need more newsletter-subscriptions!

Everything is focussed on conversion rates. More customers. More sales. More money. Optimize until you've got the sleekest and best-selling journey for your customers. (And make sure to do it cheap)

Forget about optimization. You need to do accessibility first.

When there's an accessibility issue, you're excluding people. It doesn't mean a group of people doesn't buy as much as you'd like. It means a group of people can't buy at all. They're not a tad slow in completing your customer journey. They can't even finish your customer journey.

Optimization is about being best in class. It's about being the best option for people. But if you have accessibility issues, then you're not even an option to begin with. People do not choose a competitor over you. They have no choice when you're not an option to begin with.

Where does that leave us?

If you can pick between a feature and a fix: please choose a fix. Don't optimize for some people when you're not including everybody yet.

Knowing what to expect (maybe my favorite accessibility principle)

2023-03-08T00:00:00Z

There are some useful principles to keep in mind when considering accessibility and inclusive design, but this one is probably my personal favorite. It helps a lot of people (including me, which makes it super important 👀) and can apply to so many situations. Always make sure people know what to expect.

Example #1 - The stop-and-go haircut

Let's start with a video clip I just came across on Reddit.

This is seven-year-old Ellison. He has down syndrome and struggles with sensory overload. His parents used to dread haircuts until they met Vernon Jackson, a local barber.

It's a feel-good video of a kid with down syndrome that apparently has issues with the sensory overload of getting their hair cut. In the clip you see them at a barber. The kid constantly says "stop" and "go" and the barber follows the instructions, untill the haircut is done. Both do so laughing. The kid is in control and knows exactly what to expect. This enables the haircut.

Example #2 - Presentation-progress

Have you ever been in a presentation that felt endless, and you had no idea how much more you had to endure? The uncertainty can be terrible. At least to me it can be. What helps is a Table of contents. Tell people at the beginning what you're going to tell. It helps them to know what to expect (and it helps you because clear chapters make it easier to create a presentation).

Another way to show progress is a Progressbar. I've started adding this PowerPoint-macro to my presentations. There are probably 1000 more ways to do this, this is just the way I happen to come across. The idea is that you show where you are in the presentation on every individual slide. It's a great bit of UX that is easy to add! Coincidentally, this UX can now also be found in a hobby of mine. Lego instruction booklets also feature a progress bar these days. If you're reading this and work at Lego: please share the tought process behind including this! Was it tested with audiences?

The Table of contents and Progressbar also do wonders for reading by the way. Got a big blog post or article? Add them in!

Example #3 - Signing up

Another practical example from the real life of Erik. We (my wife and I) had an option to sign our kid up for a workshop. Sign-ups opened at a certain time, and we signed up as quickly as possible. If my kid was included (there were limited spots), we would hear back.

We didn't hear back. Next workshop, we signed up even faster. We were probably not fast enough right? Wrong. Apparently somebody looked at all the sign-ups and selected who could join. Speed was not a factor.

If they had communicated this, we wouldn't have felt rushed to sign up. If they just communicate to everybody whether they were selected or not, we would not have been left in uncertainty.

We had a talk with the people organizing. They'll provide feedback to everybody next time. We now know how selection works (it's not the speed). Now we won't feel rushed. We now know what to expect. Major UX improvements for us (and other parents)!

Example #4 - Forms

Having a disability often means dealing with quite a few large organizations in your life. Whether it's for recieving benefits, being part of research or whatever reason, you're probably going to deal with a lot of forms.

(The fact that you're in your right to receive something doesn't mean you'll easily receive it. Another frustration/pet peeve of mine. I strongly dislike all the extra effort that comes to living with a disability, even though I'm thankful for all the support available.)

There forms have always been challenging. You start cheerfully because usually a form means you'll be supported in some way or another. Step X tells you you need a copy of proof Y. Then another step requires you to fill in a secondary form. Then you need to write a few paragraphs. In another step you'll need to dig out a document from your registration. And with every step you wonder how much more it will take. Maybe you emptied your evening to try and tackle the form, only to discover you won't be able to finish. And maybe you'll have another shot the next evening. And another. And another. And every failure makes it cost more energy. The form becomes insurmountable.

Recognizable? This goes for so many multi-step forms, both online and offline. Taxes are a great example. The process of applying for a job can also overlap with the issues listed. (Don't get me started on the terrible experience of trying to find a job.)

What helps? At the start of the form show how many steps there are, and what is required to fill in the entire form. Copies of documents, attachments, references, whatever is needed, please communicate it up front! It cuts up the un clear and (possibly) big task of filling in the form into smaller and more managable pieces. Instead of starting with something unmanagable and hoping you can finish, you can say "let's focus on steps 1 to N tonight". You know what to expect!

And there are plenty more

I probably run into an example of this daily. If you think about whatever you're working on, you can probably come up with some examples as well. Be upfront about what's coming, give control and communicate the status. Let people feel in control.

Who does it help?

I'd guess everybody appreciates this in some way or another, as is the case with many accessibility principles. It certainly applies to autistic people, people with brain injuries, people with AD(H)D, and probably all kinds of neurodiversity. I associate it with the executive functions of the brain.

Executive function and self-regulation skills are the mental processes that enable us to plan, focus attention, remember, and juggle multiple tasks.

Conclusion

Communicate what you're expecting from somebody, put them in control and give feedback on how that's going. Whether it's a web service, a sales process, a presentation, a job application, a meeting or anything else. This is how you empower people.

And as a side note. This blog post is an effort to post more often and more easily. This may result in less images and more typo's, but also more content in general. Thanks for taking your time to read this!

Compose your components

2023-05-09T22:00:00Z

Build the most components you can to have the least amount of work. I'll tell you why that's logical.

When you're composing your components

Let's sketch an ideal situation first. You've got (a Design System with) a component library. You want to build a new component ABCD that's a combination of components A, B, C and D. First you design, build and test these individual components in isolation. When you're done doing that, you combine them. Maybe even first as AC and BD. Or you build AB and ABC before ending with ABCD. The more steps the better!

This is the approach I like. It's agile. You iterate. You make small steps so you can't make big mistakes. You'll find bugs and issues while building and testing, but that's fine. You know where they are because you haven't built much.

When you skip the small steps

For whatever reason, you don't want the previous process. You'd rather aim for big strides than small steps. You do you, but I don't like it.

When you "instantly" build ABCD before building the smaller parts, you're taking a big risk. If you've made decisions that could've been better, you have a lot to backtrack now. For example, maybe your subcomponents aren't really reusable now, because you've built them for only one usecase. The complexity, effort and risk have all skyrocketed. Before you could test A in isolation. In this setup, if there's an issue, it could be in A, B, C or D. But it could also be in the combination of A and B, or B and D, or A and B and C or... you just don't know. There's 4 components, 6 combinations of 2 components, 4 combinations of 3 components and 1 combination of 4 components. That means a total of 15 (!) locations in which a bug or issue can manifest itself. It increases the effort of testing, but also of fixing.

And you still don't have a separate component A, B, C or D either. Those still need to be built.

Concluding

Your big strides take a lot more effort than lots of small steps combined. Especially if you discover your big step was in the wrong direction. And you still don't have the result that you would've had with little steps!

What is accessibility?

2023-05-17T22:00:00Z

Products can be made in a way that they can be used by everybody, including people with disabilities. Not everybody knows this, or how to do this. Working in the field of accessibility means supporting people to build accessible.

The universal focus state

2023-06-07T22:00:00Z

Designing a focus state? A focus state that works on every background is a great starting point. Understand how it works, and improve it for your use-case!

What is a focus state?

A lot of people use keyboards to navigate websites and apps. With a keyboard you can move (virtually) from one interactive element (like a link or button) to another. These interactive elements become "focussed". Only one element can be focussed (or "have the focus") at the same time. The foccused elemtent is pretty much your location on a page. And just like with your physical location, you can only be in one place at the same time (sadly).

The element that has the focus is your location, but also where keyboard input goes. A practical example is a text field. When a text field has focus and you start typing, your input appears in the text field. It will also accept pasted input. And when your focus is on a link or a button, you can activate it. This will trigger an action on the page or navigate you to another page.

To visually clarify what element has the focus, it's supposed to have a so-called "focus state". You might also encounter the terms "focus indicator" or "focus ring" instead of "focus state". I picked "focus state" because it's a clear term for designers. An element like a link often has multiple designed states (and combinations of states) like a focus state, an active state, a hover state and a visited state.

Browsers come with default focus states. You might have seen a blue ring around an element before, or a thin dotted outline.

Why is the focus state important?

The issue is found partially in the last sentence: "you might have seen". Focus states are not always very clear or visible. Imagine browsing the web on a desktop or laptop, without seeing your cursor. That's a bit what it's like to not have a clear focus state. You have no idea where you are!

It's very important for a user to be able to find out where they are on a page. Just like it's essential to know where your mouse cursor is. Just like how many physical maps feature a big arrow stating "you are here". You don't want to feel lost.

If there's no clear focus state, you're basically telling a lot of people you don't care about them. You don't care if they do or don't know where they are. You're excluding them. And that's why it's an accessibility issue as well. Not all people who use keyboards (or devices that work like a keyboard) have an option to use something else. They might not be able to.

What's the problem?

The problem is (not surprisingly maybe) that the focus state is not always visible. Sometimes there's a default focus state that doesn't work well, sometimes there's a custom designed focus state that's hard to see or the worst case: there's no focus state at all.

I'm not kidding here. Some websites remove the focus state entirely. For example because it's "ugly". I prefer inclusion over looks. And often it's not one or the other. A good designer can do both. (Question on the side: are you a good designer if you can't design something inclusive?)

So let's start with a big: Don't do this! Don't give your elements an "outline: 0". When you remove the outline, you remove the default focus styles and you might exclude people.

What's the solution?

A possible solution is a custom focus state that works everywhere on your app/website with all interactive elements. This can be quite a challenge. Does it work on both dark and light backgrounds? Does it work with dark-mode? Does it work with interactive elements of all kinds and colours? Quite a few questions pop up, and quite a few testing scenario's need to be covered to ensure a quality focus state

Introducing the oreo-focus

Another solution I'd like to offer is a universal focus state. One that works in all situations and is usable anywhere. Even if you do want to design your own custom focus state, maybe it's nice to start from something that you know works. You have a solid starting point to work from.

Let start with the most basic unstyled situation. Your link is blue on a white background. What gives the best contrast on a white background? Black. That's the starting point for our focus state.

But Erik, haven't you heard about dark mode? What if the background is dark or black? Good point. A black outline on a black background doesn't really give the contrast you'd like. So we add another layer to the focus state. What gives the best contrast on a black background? White. We now have an outline that's black on the inside, and another white layer around that. Wow!

It works for white backgrounds. It works for black backgrounds. Redundant approaches rock!

But Erik.... what if you have a black button on a white background? Right. Then we'd add black to black, and then white while surrounding it with white. Is everybody still following this? Let's fix this once and for all. We'll add another outline! The oreo-focus is complete!

It works with light, dark and whatever combination. I can prove this by going through a pile of test cases. This blog has been a draft on my laptop for over 4 months though. I think that shows that I can go through it, but I won't.

Show me how

It's simple (famous last words). There are 3 lines of CSS, and the third is optional.

:focus {
  outline: .375rem double black;
  box-shadow: 0 0 0 .25rem white;
  border-radius: .125rem;
}

First we select the focus state with :focus. We add a double outline that's black with outline: .375rem double black;. This is the "inner" and "outer" outline. You can read more about this outline-style on MDN.
But we want a white outline in there as well. We can add that with a box-shadow: box-shadow: 0 0 0 .25rem white;. And to make everything pretty, you can even add a border-radius: border-radius: .125rem;. Pretty right?

Show me the code

You can find the code, with examples, here: https://codepen.io/erikkroes/pen/OJEOWPN. You can go through all the test cases that I didn't. It should even work with Windows High Contrast Mode (WHCM).

Enjoy!

Notes

This whole idea and subject came up on the web-a11y slack. Throw me a message on whatever platform for an invite. I merely executed the thing and now I'm writing about it.

Further read on focus states on how they can/should be styled can be found here:

Accessibility, design systems and management.

2023-07-10T22:00:00Z

I’ve spent years working in accessibility doing everything from printing and hanging up posters, to joining and leading a Design Systems team. These days I apply my experience as a freelance consultant and these are a few of the things I’ve done recently.

Consulting is fun. Taking experience from one task to another means continuous learning. Looking back on what I've done in 6 months makes me realize: you can gain a lot of experience when you're doing a lot of things!

Leading a team of accessibility consultants

My start of the year was my end of working for Nomensa. Last year I joined their team of accessibility consultants to support them and their work for clients. What a joy it is to be surrounded by accessibility-work all the time! It's such a thankful industry to be in. I thoroughly enjoyed facilitating the team: improving their ways of working, integrating accessibility throughout the organization and developing new tools to work with. Working towards a truly unified and organized approach is a pleasure, and I'm thankful for my time with the team and all their wonderful clients. I used tools like Miro and Notion to formalize, document, create structure and gather thoughts.

Organizing a meetup

This year was the first meetup for the Dutch community for Inclusive Design & Accessibility (IDEA11Y) in quite a while. With the support of a great location and speakers, I was able to organize a get-together for the Dutch accessibility-community. (And they're such a nice group of people. They really deserve to have a platform!)
We used to have a small group to organize these things, and I've noticed it's quite a lot for one person. Recently I've asked for a bit of support and I got feedback from some people willing to help. Hopefully more meetups will follow!

Training a team of content writers

A lot of accessibility comes from sticking to conventions. Don't reinvent a wheel that works for everybody. If it works, don't touch it!
But a lot of self-expression is done through deviating from the beaten path. What should we consider when we do want to create something new? This was the challenge of the training. A very fun and creative challenge for somebody with roots in art education -and- accessibility.

When your foundation and guidelines include accessibility, it's much easier to compose and apply them to an accessible end result!

Setting up a Design System

Products need to be accessible. If you have customers within the government, odds are, it's part of the requirements!
And what better way to build something accessible, than starting from the ground up? I architected and led the development of a Design System where accessibility was a consideration in every step. When your foundation and guidelines include accessibility, it's much easier to compose and apply them to an accessible end result!
Supernova was an invaluable platform in this process, and combining it with a nicely architectured Figma-library really completed the experience.

Visualizing component dependencies

Architecting a Design System led to a small discovery. Wouldn't it be great if we could visualize dependencies of the components in a component library?

A random assortment of benefits and opportunities that were made possible:

see what components need to be finished before making a new one
see what new components are enabled when finishing a component
trace issues to the core components
communicate that the value of a component goes beyond a single component (but contributes to a larger system)
get an overview of what you're building and what to prioritize

As you might pick up from my enthusiasm about the possibilities, I very much enjoyed building this tool. I used Airtable to index components, Python to understand relationships and Graphviz to create an invaluable SVG-visualization of it all. It was a bit like the art academy and creative coding again for me. I used code (and analysis) to create an image and gain insight. It was like re-discovering a passion!

This image gives an idea of what can be visualized. This example is raw, unstyled and rather chaotic. But depending on your application, it can take many shapes!
Technically speaking "it's just an SVG-file", which means it's easy to use with HTML and CSS. Styling can be done different, details can be shown when hovering, components and depedencies can be isolated. A lot of possibilities are imaginable!

Auditing a component library and website

Why do we (accessibility consultants) audit pages when they're built out of components? For compliance, one might say.
The days of building websites page-by-page are quite a while behind us. These days we build components and compose those until we get templates and pages. This means that fixing an issue in one component, fixes it for many pages. But it also means that finding an issue on one page, probably also means finding it on other pages with the same component.
I don't like superfluous repetition, and neither did this client. I audited their component library to find issues at the source. I followed "the path of composition" towards full templates and pages to find out if any new issues were introduced.
Now the client has a report that's extremely actionable, because they know exactly where they should look to improve the user experience of their website.

Developing a new product from scratch

A lot of my skills and experience are now coming together in a new project. I'm developing a "Design System as a Service"-product. Coming up with the business model, writing standard operating procedures, selecting and setting up tools and technologies, managing people, content, design and code... there are so many facets to this project and I'm enjoying every one of them!

What's next?

Well vacation is what's next, that's for sure. I've been enjoying sharing my skills and experience (and energy) but I can't share without recharging every now and then!
The "product development"-project is still ongoing. Things are on track for more IDEA11Y-meetups in the near future. I'd also love to spend some time on (re-)vitalizing the community even more.
Another project on the agenda is to support an extensive accessibility-team in their journey. I'm looking forward to share what I can, and facilitate their uphill struggle towards a constructive journey.
If there's anything I can do for you let me know. I always love to hear about both ongoing projects that I can contribute to, and incidental opportunities like training and speaking. Let me know what you'd like to pick my brain about!

What you should (not) put inside an anchor link

2023-07-17T22:00:00Z

The anchor link is one of the most elemental of HTML-elements. The idea of linking things is kind of the core idea of HyperText (the HT in both HTML and HTTP). And oh my, do we love to (ab)use links on the web!

What's the problem?

What we put inside a link (in between and ) is what becomes clickable and opens the link. That's assuming you're using a mouse.
If you're on a touch screen, it's what becomes touchable. If you're using a keyboard, it's the part you can activate. It's the part that's interactive!
However, what we put inside a link can also be the "accessible name" of the link. W3 has a lengthy description on what an accessible name is. MDN has a less lengthy description. I think MDNs description starts of pretty well:

An accessible name is the name of a user interface element; it is the text associated with an HTML element that provides users of assistive technology with a label for the element.

If somebody visits your website with assistive technology (like a screen reader) then the accessible name is what identifies an element.
If somebody visits your website with assistive technology, all your links are named "click here" and they ask for a list of links, they'll get a list with each item called "click here".
If somebody visits your website with assistive technology, you've got some interactive elements containing images, headings and paragraphs of text, the interactive elements will have a -very- lengthy name.

So there's the problem in a nutshell. What you want to be interactive often determines the accessible name. But what's interactive and a name are often two different things.

How is the accessible name calculated

W3 has a page named Accessible Name and Description Computation with lots of technical details. It describes how various elements are named. (Because it can vary per element. can have alt but

can not.)
Common ways to name a link, in order of priority:

aria-labelledby
aria-label
Content

Aria-labelledby

Identifies the element (or elements) that labels the current element. See related aria-describedby.

Read more about it in WAI-ARIA 1.2.
aria-labelledby is an attribute that takes one or multiple "IDs". The accessible names of these elements are concatenated and form the accessible name of the parent element.
A practical use case is adding aria-labelledby to an HTML landmark, and making it refer to a relevant heading. This way the heading names the landmark.
But adding aria-labelledby is a conscious action, you might not always have something to refer to and the First rule of ARIA use applies as well:

If you can use a native HTML element or attribute (...), then do so.

Aria-label

If there's no suitable aria-labelledby, then maybe aria-label can be used! It's a bit more straightforward. The value of the attribute becomes the accessible name. Or as described in WAI-ARIA 1.2:

Defines a string value that labels the current element. See related aria-labelledby.

For this attribute, the first rule of ARIA use still applies. It can be useful however when dealing with something like a CMS, and you can't change the content (but you -can- influence the aria-label).

Content

This is the most common situation. The aria-attributes need to be added explicitly but content is usually there. Content is like a default when browsers come up with the accessible name.
This is a common pattern: Learn more about me. It creates a link named "about" that refers to a href-value (currently unset).
When you've got a link with lots of content (like a card-pattern), all the content can become the accessible name of the link.

What we could learn from this

The content of a link often becomes the accessible name of the link.
We want:

Descriptive: the name should describe the target of the link. Especially relevant with paragraphs of text and images with alt text.
Unique: this aligns with being descriptive. If different links have the same name, how do we know which is which?
Succinct: Long names are unpleasant to use and harder to maintain

Aria-roles do very little

2023-09-11T22:00:00Z

Look at modern websites at you'll see their code covered in aria-roles: a pretty

with role="button" here, a nice with role="link" further along, and so on. But what is an aria-role, and what does it actually do?

This all started (for me) with a question I asked recently. I asked if people could tell me what the accessible name is of the following element:

I'm the contents

It's a bit of a trick question. Sorry. It was part of the fun for me. But now let's turn it into something educational!

The first thoughts for some people seemed to be something like the following:

The element has an image-role.
The accessible name of an image can be set by an alt-attribute
The alt-attribute determines the accessible name

So let's have a quick look at aria-roles.

What is WAI-ARIA?

I wrote aria but it's actually the Web Accessibility Initiative - Accessible Rich Internet Applications (WAI-ARIA). So I write aria.
You could see aria as an extension of HTML. It offers additional attributes that you can add to your HTML. Unsurprisingly: these attributes (can) improve accessibility!

Aria can be added to communicate roles, states and properties. We're looking at roles in this case. If there's anything you pick up from reading this, it might as well be the following. The First Rule of ARIA Use:

If you can use a native HTML element or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so.

In other words: use HTML when you can. Eric Bailey's "ARIA is Spackle, Not Rebar" is still very current.

Do aria-roles add keyboard interaction?

No. It won't make your custom checkboxes navigable with arrows. It won't turn make me able to switch between your tabs. It won't even make anything focusable by keyboard.

Do aria-roles make things clickable?

Nope. A

with an aria-role will interact with your mouse -exactly- like a

without one.

Do aria-roles show I care about accessibility?

Not really. It might show you know aria-roles exist. It might just mean you're good at copy/pasting things. Aria is not a good or bad practice in itself.

Do aria-roles override the HTML-element?

Nope. The previous questions and examples might already answer that a bit. A

with a button-role is still a

. It still has the same allowed attributes as any other

This also means (and this is an interesting bit) that adding a role="img" does not make an element support an alt. How the accessible name is calculated does not change!

Do aria-roles add sparkles? Glitter? Magic?

No. None of that. And I'm not a big fan of glitter really. So I take that as a win.

What do aria-roles do then?

Not much and a whole lot. Aria-roles change the semantics of an element. It changes what an element communicates it is.
So a

communicates (in code) that it intends to be an image. This is essential in any situation where the visuals of an element don't play a role. For example, when somebody can not see

is actually a



Accessibility is not binary
2023-09-20T22:00:00Z

                Often when people talk about accessibility, it appears to be this binary thing. Something either is or isn’t accessible. And that’s true, but it also isn’t.

Is it accessible?
I learned a lot about accessibility with this mindset. I’ve always thought of accessibility as a bridge. You can fix 99% of the bridge, but if one section is missing, people still can’t cross. A bridge with holes isn’t a finished bridge. There’s still work to do!
When you think of accessibility as a subject for business, it’s probably true! Let’s frame it as a user story: As a business I want to comply with WCAG 2.1 AA so I can avoid law suits.
And that’s the thing right? For a lot of people(/businesses) being accessible means being compliant with WCAG (Web Content Accessibility Guidelines) 2.1 AA. And yes, the question “Is this compliant?” can be answered with a hard yes or no.
And that’s where audits come in. An audit is when a specialist inspects your website (or app?). Often they follow the methodology WCAG-EM. Their findings go into a big report that states wether you’re accessible (complying with WCAG 2.1 AA) or not, and what you need to fix.
In a world where goals and targets are decided by those in management, compliance will often be the target. And in such a situation, an audit is very logical.
Is it valuable?
But do I believe that is what accessibility is about? It’s the frame I always had but no, accessibility is a spectrum. Even when you’re not fully accessible (WCAG 2.1 AA compliant), you can still be more accessible than other iterations/the competition.
You might still be excluding people, but that doesn’t mean there are no improvements. I’d still aim for WCAG-compliance. There’s a reason these guidelines end up in regulations all over the world: they’re pretty good. But it also a minimum. It’s the legal requirement in many situations that will avoid getting you sued. It’s not the ideal standard that will ensure everybody will have a great time interacting with your website.
But don’t forget to be proud when you’re making steps -towards- compliance. When your product is audited, and you’ve fixed previous issues... that’s improvement! You’re including -more- people than before. And that’s valuable! Be proud of what you’ve achieved and what you’ve learned!
Concluding
Audits are a great tool for compliance. They’re an external collection of findings. Taking the point of view of somebody building something, it might not be the most valuable feedback. A modern workflow start with components and does not revolve around the delivered pages. So you want your feedback to be shaped like that as well.
If you’re going for something that’s not just compliance, I would advice looking from the ground up. Make accessibility part of the requirements, incorporate it in your foundations (like design systems and component libraries), focus on it during design, make it part of your handovers, consider it while building and double-check it when delivering.
Something as foundational as accessibility can be judged with an audit, but just looking at the end-result won’t fix it. Even when you aim for compliance, it’ll be hard to reach from an audit.

            


An audit won't solve your issues
2023-10-04T22:00:00Z

                Accessibility audits are great, except when you want to solve issues. Structural issues require inspection beyond the surface, and solutions beyond patching up.
What is an accessibility audit?
An accessibility audit is an evaluation of your website or app by an accessibility specialist. Often they'll follow the Website Accessibility Conformance Evaluation Methodology (WCAG-EM) and check if your digital property conforms to the Web Content Accessibility Guidelines (WCAG).

In practice, this means you'll define what needs to be audited and select a representative sample together. The specialist then does a thorough evaluation of these selected pages, and creates a report mentioning everything that must be improved for conformance.
(And then this beefy report vanishes in a drawer, never to be seen again. No, not really. But this is the fear of many auditors, and might be a failure of the report. A good report ideally tells you what can be improved, why it should be improved and how it should be improved. It's understandable and actionable. And I hope there aren't any in your drawers.)
What's the problem then?
There's not exactly a problem. Audits are great for compliance. They're great for checking what the state of things is. A doctor also starts by checking symptoms. But that's the thing. An audit looks at an end-result. Often what's found in an audit is a sign or indication of something underlying. It tells you about a systemic issue.
Time for an analogy!
Imagine you're going to a restaurant. You order soup. (I don't order soup very often but it's practical for the analogy.) You take a good look at your soup and you discover a hair. That's not how you'd want to eat your soup. The hair is removed or you get new soup, restaurants vary, and you now have eatable soup.
This means the issue is fixed right? There was a problem. It was spotted. It was handled. Done!
Removing one hair fixes one instance. And that's fine. You don't want to wait for your soup while they fix this once and for all. You just want soup.
But that's the thing that should follow from this. They should have a thorough look of where this hair came from. Do more hairs end up in soup? Is hygiene being taken seriously in the kitchen? By everybody? They don't want to worry about hairs with every cup of soup that goes out. Maybe it happens with other meals as well, but they just haven't noticed!
An audit is a way to spot a symptom or an outcome at one point in time. But if you actually want to solve the issue structurally, also for new versions, other instances, variations, etc.. you'll have to dig deeper.
How do we dig deeper?
Now that's the challenge of a good accessibility-focussed person. They could start at the audit report and analyze. Is the issue a one-off, or does it happen more often? Does it always happen in the same component, or feature? Is it more widespread? Is there an underlying issue maybe, that causes multiple issues on the surface? Is it a misunderstanding that needs training? Is it a reusable component that needs a fix?
Or they could start from somewhere else. Pages and apps aren't built in isolation these days. Often they're started from something much more abstract. They might start with requirements, branding guidelines and foundational design agreements. Those might be turned into a specification. Then the specification gets designed. Annotations are added to the design. A developer starts working on the annotated design. There's some back and forth between the designer and the developer. The developer delivers a component.

Then the whole cycle might start again for an even bigger component that's composed of multiple smaller components. And another cycle. And then the really big components become a feature. And multiple features become a webpage.
That's how modern websites get built in large organizations (or a variation of that process). For structural solutions, I suggest follow the same route. Don't start at the end. A muffin that you try to stuff with some blueberries after baking... just isn't the same as a blueberry muffin. Accessibility issues should be tackled at the source, not patched up in the end-result.
So when you audit a website to improve accessibility, and not just reach compliance, maybe start at the components. Maybe first look at those structural building blocks that get reused and are the foundation of every page on the site. Then see how those blocks are composed. Does that introduce new issues? Are they used properly? Maybe there's something in the documentation that can be improved?

Then follow the "route of composition" until you reach the end result. Keep tracking if issues are caused. You'll know exactly where problems are introduced when following this route. Which means, you'll know exactly where to fix them as well.
Concluding
There's some overlap with something I wrote before called Compose your components. And it all sounds so logical (at least to me) when looking at it like this. How we build websites has changed, but auditing has not.

You can’t make grass grow faster by pulling on it. If you want to fix your grass, find out why it's growing like it does. Change the soil, fertilize, water, cut.. do whatever's needed but look beyond the obvious if you want a root cause. An audit spots the tip of the iceberg (hence the image of the iceberg I added to this writing) but you wan't to know what's beneath the surface.
If you want to make something accessible, focus on the cause and not the symptoms.

            


Burn your toast
2023-10-16T22:00:00Z

                There's a simple question I ask myself whenever I consider the usage of a toast-component.

What is a toast?
A toast is a non-modal notification that often popups at the bottom of the screen. At least, that's the most common implementation. It may be in another spot sometimes. It may or may not contain interactive content. Sometimes even multiple items. It may or may not disappear by itself. It may also be called a snackbar.
What do you ask yourself?
When I consider the usage of a toast-component, I find only one question relevant. Is the content essential?
If it's a yes, the content should be put in a valuable location and I don't use a toast.

If it's a no, the content isn't needed, should be scrapped, and I don't use a toast.
Why does this work so well?
It might not be a surprise at this point, but I don't like toasts. Toasts are bad. They're this tiny popup in the corner of your eye that may or may not disappear. It means I'm being rushed! Is it fine if I miss it? Quick, I need to read it before it might go away! How long has is been there already? They're anxiety-inducing!
There's a reason there's a Succes Criterion (SC 2.2.1 - Timing Adjustable) in the Web Content Accessibility Guidelines that's concerned with timings.
And that's not enough. Toasts are often at the end of the DOM (the code that makes up the page). This makes it extra hard for people with screen readers to notice them, let alone navigate to them. And you'll miss them when you're focussed on another task (probably the one that triggers it in the first place). And you'll miss then when you're distracted. And basically, odds are you'll miss them.
And even when you do notice it, you might not be fast enough to do anything with it. Like read it. Make a decisision based on it. Or trigger whatever action shows. Or you did make your decisision but then it vanishes. Sounds like fun right? (No it doesn't. I'm sarcastic.)
An example
I use Gmail on the web. It has a toast. Whenever you send a message, you get a quick toast that give you the option to undo it. If you're not fast enough, the option to undo goes away. It's life-saving when it works. It never does though. I can count on one hand the times I've succesfully used it. And I use Gmail a -lot-. I even tried to make a screenshot of it, but I wasn't fast enough. Even when prepared, I missed it. That's how useful it is.

It still gave me anxiety though. Task failed succesfully.
Concluding
If you care about your communication, don't use toast. And if you don't, still don't use it because you'll give people anxiety.
Other people wrote about this subject in a much more nuanced way. Feel free to read their thoughts before you burn your toast.

https://www.scottohara.me/blog/2019/07/08/a-toast-to-a11y-toasts.html
https://adrianroselli.com/2019/06/scraping-burned-toast.html
https://css-tricks.com/toast/


            


Let's start a club
2023-10-24T22:00:00Z

                Newsletters aren't for me. I do love sharing though. I came up with some alternatives including a Discord server. Let me share with you why I think that's a good idea.
I've seen several people in my "bubble" start newsletters. I think that's great. Moving away from unstable platforms and walled gardens and creating a channel for sharing.

I'd love to run a successful newsletter. But I won't. It's not a good fit for me, or for how my head works.

I've been considering what would work for me instead. This is what I came up with:

I've set up two sections on my website. One for my blog (which I already had) and one for Notes. Notes are the short messages you'd expect on twitter, mastodon, platforms like those. I will publish these on my site, and syndicate elsewhere (POSSE). This means I'll write something on my own site, and it'll show up shortly after in several channels:

RSS: https://www.erikkroes.nl/notes/feed.xml
Mastodon: https://mastodon.social/@erikKroes
Twitter: https://www.twitter.com/erikkroes
Discord (more on that later): https://discord.gg/FSRZDPDzrQ
I also want to publish on Flickr, Pixelfed and LinkedIn but my crude setup doesn't allow that yet. I hope all this makes sure you can find my content wherever you like.


My second action is setting up a Discord server. Discord is like a modern IRC. Or Slack but with an archive and more integrations. To be honest, I'm not a big fan. I still have a ton of options to configure and make the space as usable and inclusive as possible. But I think it's the best tool for the job right now.

Join my Discord!
This is the part where I get you enthusiastic about joining. I mean, a place to chat is nice and all. But it's a lot nicer when I'm not alone in there.

Why I think you should join:

You won't miss any of my writings. Both good and bad.
You won't miss the discussion around the writings (which, honestly, is often at least as valuable)
Brainpicking! I'll be there to share my knowledge and experience, but I hope you will be as well. I'd love to learn from you!
Discounts. I'm looking forward to find some nice offers, specifically to share and enjoy together
Input. I'd like to create more content, and I want the people in my Discord to suggest topics and subjects. Let me share, dive in and explain whenever possible. I prefer spending my energy on things you all care about!
More discounts. If I'm going to make big things like books, courses and digital assets, you bet I'll drop some discounts.
A passionate and inclusive community! I hope to gather a nice group of people (including you). It's one of the reasons I landed in the field of accessibility: so many nice people!

So join! Let's gather up some nice people and improve ourselves together. This is an invite link that works for at least 7 days, but feel free to invite other people as well! [https://discord.gg/FSRZDPDzrQ]https://discord.gg/FSRZDPDzrQ)
Disclaimer
This is a bit of an experiment. It's something quite unusual to do (for me). I would really appreciate your input and feedback. That way I can iterate and improve things, and together we can create a nice little space on the web. Remember forums? Those were nice. Sigh.

            


The added value of (neuro)diversity
2023-10-26T22:00:00Z

                People like people who are like them. That's practical for making friends. It's not when you want a well-rounded team.


A bit of background
Diversity to the rescue
What is diversity?

Neurodiversity


Diversity is not a superpower
(Personal) conclusion


A bit of background
There's this thing called "affinity bias". It's when people tend to like people who are a lot like them. It's one of a ton of biases that Wikipedia explains better than I do.
The thing with these biases is, they tend to cloud your judgment. This is especially clear when hiring (and promoting) people. People like people that are like them, so they're the ones that get hired and promoted. If this goes unchecked, you end up with teams full of people that are alike. Managements levels of people that are alike. Companies full of people that are alike. You gravitate towards echo chambers where everybody agrees, everybody says yes, and nobody offers a different perspective.
Diversity to the rescue
You can counter that with diversity. A person with a different background might spot new problems that would've been missed otherwise. A person with a different perspective might think of solutions that weren't thought of before.

Diversity brings creativity. Diversity brings awareness. Diversity brings experience. A diverse team has a much broader set of skills and is much more flexible!
It feels like such an obvious thing to be writing about, but that's probably the thing with biases. You're often not aware until somebody points them out. (And that's complicated, because if you're surrounded by people like you, maybe nobody will point it out.)
What is diversity?
There are so many angles to diversity, that trying to list them is probably a recipe for failure. I'll mention a few, but you'll probably know some groups of people that I don't. For example, you could be working with people all around the same age and are practicing ageism. But what about other traits? Think of gender, race or culture. The cultural one is one I've experienced personally and seems to be overlooked often. A group of people with the same cultural background (hi Reddit) often lacks diversity.
Another one is ableism. Are people with disabilities included? It makes it much easier to build inclusive products and have inclusivity on your road map, when you include people with disabilities in your process. "Nothing about us without us" is a popular slogan that goes beyond disability rights.
Neurodiversity
I'd like to mention Neurodiversity specifically. I'm not even sure how to define it, if there is even one definition that could cover it. Neurodiversity is a term for people with atypical traits. This often includes people who are autistic, people with ADHD, dyslexia and all kinds of factors that deviate from how people (and mostly their brains) typically are.

As neurodiverse people are often "wired differently", they can be very good at adding perspectives and insights to conversations. The challenge is to let them contribute.
If somebody would investigate the prevalence of neurodiversity among developers and designers, I'd expect it to be above average. They're some of the most focussed and creative people you'll ever meet. If somebody would investigate the prevalence of neurodiversity among managers, I'd expect it to be below average. Outliers don't get promoted.
Diversity is not a superpower
Reading this, and many other articles, you might think diversity is a gift. Like it's inherently beneficial to be diverse. It's not. As I said, diversity can keep you from being hired and/or promoted. You're up against a very common and subtle bias that reinforces itself. If studied, I wouldn't be surprised if it's a bias that's deeply ingrained in many organizations.
As a diverse person, you're an outsider by default. And you often have to work extra hard to integrate (as you're not welcome by default).
(Personal) conclusion
Being diverse is often no fun. I'm neurodiverse in 3 different ways, and no, they don't cancel each other out. In most situations, you start with a disadvantage.
I consider it as a great benefit though. As an accessibility consultant, it's very useful. My neurodiversity means I'm pretty much always able to give a new perspective, to add to a conversation and give a new angle. I'm good at throwing curveballs, if I had to say it more US-centric.
People hire me to add value. I'm very good at that. It's what I've been doing all my life. I'm an outlier trying to make the world better for outliers.

            


Politieke partijen niet digitaal toegankelijk
2023-11-08T00:00:00Z

                Onderzoek wijst uit dat alle landelijke politieke partijen mensen digitaal uitsluiten. Een groot deel van de bevolking heeft geen toegang tot hun website.

Op 22 november doen er 20 partijen landelijk mee aan de verkiezingen. Van elke partij is de website beoordeeld op digitale toegankelijkheid met een automatische test. Overheden zijn verplicht om toegankelijk te zijn voor alle burgers, inclusief mensen met een beperking. Alle getoetste websites hadden fouten waardoor ze ontoegankelijk zijn.
Wat is digitale toegankelijkheid, en waarom is het belangrijk?
Digitale producten kunnen zo gebouwd worden dat ze voor iedereen toegankelijk zijn, ook mensen met een beperking. Voor de overheid is dit zelfs verplicht. Niet toegankelijk bouwen leidt tot het uitsluiten van mensen met beperkingen (wereldwijd ongeveer 1.3 miljard mensen)

Het is een recht voor iedereen om mee te kunnen doen in de maatschappij. Dit is onder andere vastgelegd in het Verdrag inzake de rechten van personen met een handicap uit 2006.
Wat is automatisch testen?
Er zijn meer dan 70 criteria waar iemand toegankelijkheid op kan testen. De meeste van dezen zijn alleen handmatig (door een persoon) te testen. Slechts een kleine groep van deze criteria is automatisch te testen. Het doorstaan van een automatische test is daarmee geen garantie voor toegankelijkheid. Het falen van een automatische test is wel een bewijs dat er sowieso tekortkomingen zijn.
De resultaten



Partij
Getest adres
Gevonden fouten




VVD
https://www.vvd.nl/
18


D66
https://d66.nl/
11


GroenlinksPvdA
https://groenlinkspvda.nl/
6


PVV
https://www.pvv.nl/
6


CDA
https://www.cda.nl/
15


SP
https://verkiezingen.sp.nl/
23


FvD
https://fvd.nl/
23


PvdD
https://www.partijvoordedieren.nl/
11


CU
https://www.christenunie.nl/
84


Volt
https://voltnederland.org/
18


JA21
https://ja21.nl/
32


SGP
https://sgp.nl/home
23


Denk
https://www.bewegingdenk.nl/
43


50PLUS
https://50pluspartij.nl/
9


BBB
https://boerburgerbeweging.nl/
20


BIJ1
https://bij1.org/
11


Piratenpartij
https://piratenpartij.nl/
9


BVNL
https://bvnl.nl/
12


NSC
https://partijnieuwsociaalcontract.nl/
3


Splinter
https://www.splinterpolitiek.nl/
14



Alle partijen werpen barrières op voor bezoekers aan hun website. Dit maakt hun verkiezingsprogramma's en standpunten onbereikbaar voor een grote groep mensen. Zij kunnen zich niet op dezelfde manier laten informeren over de verkiezingen als mensen zonder een beperking.

            


No, your website does not have a mobile version
2024-02-09T00:00:00Z

                Designers often (if they're nice) design multiple versions of a website. The designs get names like "mobile version", "tablet version" and "desktop version". I appreciate the effort, but I've noticed confusion stemming from these terms. They are often counterproductive.


The assumptions

It's not just touch
It's not just small screens


Alternative terms
Conclusion


The assumptions
The image that lives in many minds when talking about a "mobile version": "It's what people use on their mobile phone. They're using a device with a small screen and control it with touch."

I'm afraid there are some faulty assumptions in that thought. Let me highlight some of those, and offer ideas for a different term (that hopefully doesn't carry any faulty assumptions).
It's not just touch
While mobile phones often have a touch screen, it's certainly not the only way to control them. People can use external keyboards instead. People can use a screen reader to control their phone. There's Switch Control or Switch Access. All of those rely on being able to operate a website with a keyboard.

And then there's also voice control, which does not rely on the keyboard, but does show there's a whole world beyond touch.

Those are just some (sort of) common ways to control a phone beyond touch. The world of assistive technology is rich and features many more ways and devices.
It's not just small screens
What do phones have these days? About 4-7 inches of screen I guess? But "mobile versions" are not restricted to phones. They are often the version of a website that shows up at a certain resolution, not screen size.

What this practically means that if a user uses a browser on a different device (like a laptop or computer) and they zoom in, they also get this "mobile version"!

And this is also very relevant for accessibility: a lot of users zoom in on websites! And there are plenty of websites that already change their layout and start showing a (more) "mobile version" when zooming in at only 125-150%. That's not a lot! Browsers can easily zoom up to 500%.

So no, your "mobile version" is not restricted to small screens. And when you imagine users with desktops or laptops, it might also be easier to imagine they're not using touch either.
Alternative terms
I'd like to get rid of the term mobile or anything phone-related in this context. Also nothing with "small", as that might create assumptions about the screen size.

I can imagine "zoomed in version" already removing some of the stigma. It still draws attention to a specific use case.

How about "version for low resolutions"? As in the end, that's what determines wether a version gets show or not: the resolution it's presented in. I can use a version for low resolutions on a large display. I can use a version for high resolutions on a small display. It feels like a fitting definition.

Join the Discord community and share what you think is a good term! (Link at the end of this blog)
Conclusion
So a mobile verson is not just for small screens. And even if it were, it's also not restricted to touch only. If you're making a website, and you've got a design for a "mobile version", it should conform to -everything- that all other designs conform to. It should be just as accessible with a keyboard, and it should offer all the same content and functionality.

The fact that not all people can access the fanciest high-resolution version of a website, does not mean they should be missing out on content or functionality.

            


A tool for sharing messages and images
2024-03-18T23:00:00Z

                I've been looking for something for months. It's a tool that's a mix of IndieWeb, accessibility and nonexistence. There are plenty of tools out there that do -some- of what I want. But none of them seem to do all of it. I'm now calling for your help. I'm looking for a programmer to build this.

The idea is simple (in my mind). I want to post short messages on my website, and I want them to be syndicated elsewhere. In the terms of IndieWeb, this would be POSSE. The tough part seems to be posting short messages with images -and- a text alternative. This is crucial to me, but this is where most tools fall short.
I've tried existing tools, programming my own in several ways and even low-code tools. Exploring has included trying all kinds of new technologies and even diving into the RSS-spec. All of my attempts have run into barriers. (Some of them being time and energy) My best option now is counter-intuitive. I'm not going to do this myself. I'd like somebody to fix this for me 🤞🏿
Some technical bits on the current situation. My website runs on Eleventy. My implementation is open source and you can find my entire website on Github.

All my posts start as a bit of Markdown that I write in TinaCMS. The CMS pushes a file to GitHub. It's then built/published/hosted on Netlify. The messages I write appear on my website (like this blog) and in an RSS-feed.
What I'd like is the following. I want my notes to be published from my website to Mastodon, Discord, Twitter and LinkedIn. Ideally also to Bluesky, Pixelfed and Flickr. Ideally I'd have default flows and/or ways to select platforms to publish to.

For example, I'd like photography to be posted to Pixelfed and Flickr but probably not LinkedIn.

A first version could be posting just text to Mastodon. Then iterations could be done to add more platforms and functionality. And I'd like the result to be something I can share freely with other people.
So who wants to help me out with this? I can imagine that for some people, most of this can be done in an evening. I'd love to find somebody with such experience!

Considering the time I've already spent on this, I think it's also very reasonable to turn this into a paid assignment.
Please let me know if you're able to fix this. I've been posting pretty much nothing but text for months. I'm looking forward to share bad memes and pictures again!

            


Be flexible about what people need (and don't assume).
2024-03-25T23:00:00Z

                Your assumptions about facilitation and accommodation can be wrong. They're often shaped differently and smaller than you think. Awareness is key.

You might have come across the term "accommodation" in the context of disability. Maybe it was during a hiring process, and you were asked if you needed any accommodations. It could've been buying a ticket for an event. It can also be in a learning-environment. Or during travel.
You might have an idea what an accommodation could be. You could be thinking of audio versions of text, materials with a large print, materials in braille, specific software, sign language, the list goes on.
When you search for examples of accommodations on the web, they tend to be quite big. They might require preparations, physical changes to spaces or arrangements (like seating) or even specific people being present. But did you know accommodations can also be quite small? Sometimes the biggest difference is in awareness.
This week I had a funny situation. Or at least, I found it funny. I went to the dentist (not really the funny part). Before my appointment I went to the desk. I asked the person behind the desk to remind me that I had to pay after my appointment. They agreed to do so.
I have a collection of disabilities including an acquired brain injury. It means planning and organization don't come naturally, and I'm very focussed on doing those properly. So when I asked the person to remind me, that was actually a request for help. I was asking her to help me, and facilitate me and my disabilities.
After my appointment, I was not reminded of my open payment. And, not unexpected to me, I left without paying.
Now the dentist did hear my question, and the reply, and he was aware of my disabilities. Now you can imagine that a customer leaving without paying might make him angry. I would've understood if he were upset with me, maybe even angry.
But he wasn't angry at me. He wasn't happy though. He was wondering why I wasn't reminded of my payment. I specifically asked (I was actually a bit proud of that) but I wasn't reminded. He recognized my question as a request for help. He completely understood I had walked out!
The dentist told me when I was at the practice again. I laughed when I found out (and I paid of course).
The difference between these two people was awareness. My disability didn't need much help (I think), just a small reminder. People with disabilities are often very well schooled on the subject of their disability. They know very well what their needs are. Sometimes all we need to do is listen, be aware and be a bit flexible.

            


The unclear case of usability widgets on your website
2024-06-03T22:00:00Z

                There are lots of tools/addons/widgets you can add to your website, with the intent of improving usability or accessibility. You can also build multiple versions and variations, to cater to different people and needs (or for compliance).

Should you or shouldn't you do this?
The downsides
I've been quite conflicted about this. Let's start with the downsides first.

My background is as a developer. I also like to believe I have a sense for business. Doing anything twice feels incredibly wasteful.

For example: you're building a low contrast website with brand colors. You offer a second version with a higher contrast (usually for accessibility).

This would mean you basically run two websites. Maintenance, security, testing, accessibility... pretty much everything (except for checking contrast) needs to be done twice. That does not appeal to me. At all.

I don't find it very inclusive either. You have a special website for "special people", or something alike? The inclusive solution (in my opinion) would be to have one website for everybody. And if that website is good, then everybody can benefit from a nice and proper contrast.

So that's:

possible superfluous work,
lack of inclusion and
not benefitting all visitors.

Another point that aligns with the (lack of) inclusion is having to declare a need. As a visitor it's like you have to say "I have a disability" because you need to make a conscious choice to use a different version of the website. It can be rather confrontational. Experiences like these are quite negative for me.

Also good to know is that people with disabilities often have lots of tooling available. They know their limits better than you. Build a proper accessible website, and their tools will be able to deal with it.
The upsides
But then there are some upsides as well. The first can be rather commercial. There's value in communicating that you care about the user experience. By putting up a button that reads a page out loud, you communicate a positive message.

You're also adding value for people who don't consider themselves as having a disability, or don't want to confirm or acknowledge such. Let's say you're having trouble reading a website, but you don't want to call yourself dyslexic. You could use the button already present. You're not required acknowledge a disability, and to learn about tooling. It's already present.

And finally, assuming your addition doesn't exclude anybody, then there's no harm in adding it right?  If your addition is beneficial to some, but doesn't exclude anybody else. Sounds like it's valid to try it out then!

Common customizations in this category are typography, contrast and reading text out loud.
Where does that leave us?
I wouldn't depend on a widget, alternative versions or anything alike to enable access. Create the best experience you can, and let everybody enjoy it. If you can improve the experience for some, while not harming others, I lean towards doing so.

            


How to find the accessible name  of a button with Google Chrome
2024-09-10T22:00:00Z

                You just ran an automated test and it tells you your buttons don't have accessible names. What does that mean, why does it matter, and how do you check this yourself?


What is an accessible name?
Why do accessible names matter?
How do I check for accessible names on buttons?

What does the Accessibility pane show?
What more is in the sub-section?


Note


What is an accessible name?

  
    
       The accessible name of an element is the label by which it can be referred. For example, it provides users of assistive technology with a label for the element.
    
    
    Definition of Accessible name in my Glossary
    
  

For full clarity in the context of a button. This is not the same as the value of the name-attribute.
Why do accessible names matter?
When you follow purely legal and compliance-reasons, WCAG Success Criterion 4.1.2 requires user interface components to have an accessible name.

An accessible name is a way to identify a component. It means that a person using a screen-reader can find out what the purpose is of a component. Where does a link lead? What does a button do? What input is required? And the same goes for other types for  assistive-technology. For example, a person that uses voice control knows what to call a button, when it asks for a button to be activated.

So in short, accessible names make it possible to identify components. Without accessible names, a website would be like a hallway of unmarked doors.

And if you didn't come up with this already, this goes for more than buttons. But buttons are just such a practical example to get started with!
How do I check for accessible names on buttons?

Find a button. To check if a button has an accessible name, we first need a button!
Open your Chrome DevTools. You should open Chrome, open the page that contains the button you would like to check, and open Chrome Devtools.
Open the Accessibility pane. This is a great tool inside Chrome that shows you tons of accessibility-related information. Please do dive in further!
Inspect the button. Is inspect the right term? Maybe it's select. Make sure that in your DevTools, the button-element is selected.
Check if the button has an accessible name. With your button selected, the Accessibility pane will show information about the button. Let's go through the information that's shown.

What does the Accessibility pane show?

The first section is a rendering of the accessibility-tree. This goes beyond just the button, and shows it in a context.
The second section shows aria attributes. These may or may not be present. This is situation-dependant, and is not a good or bad sign by itself.
The third second is the "Computed Properties". This is the part that we're now interested in. The first sub-section here is called "Name".

Assuming you want your button to be named "Menu", the sub-section should be labelled: Name: "Menu". If your button is not named, it will state: Name: "".
That concludes what we want to check here. We basically have 2 options:

Name: "". This means there's no accessible name. Which means your page has accessibility-issues and does not comply with WCAG SC 4.1.2.
Anything else. You've got an accessible name! You'll still have to check if it's the one you intended, and if it's even a good name. I mean, it could be some unreadable character from an icon font. But it's not missing, and that's good!

What more is in the sub-section?
For the purpose of finding a name, we didn't need to expand the sub-section. But it can be expanded, and there's some interesting stuff in there!

When looking at a button, you can expect 5 items there:

aria-labelledby
aria-label
From label
Contents
title

These are the steps Chrome goes through to calculate/compute the accessible name. That's the idea between calling this section "Computed Properties". The name is the result of a computation. How the computation works can be read in "Accessible Name and Description Computation 1.2"; a W3C Working Draft from 2024. But using Chrome can be much faster an easier.
What Chrome does is go through the 5 items mentioned before, and use the information to compute the accessible name.

First it checks if there's a relevant aria-labelledby-attribute. This attribute can refer to one or multiple IDs of other elements, that together result in an accessible name. It can refer to one element, but it can also concatenate multiple.
The second option is an aria-label-attribute. This attribute accepts a string that will label the element.
Just like an , buttons can also be labeled with a correctly referenced -element.
An accessible name can also be computed from the contents. This is probably your most common way of naming things. For example, you might have a button that opens a menu: . The content is used in this case. Good to know: sometimes buttons have nothing more than images (like icons) in them. The image is then the content. The accessible name of the image is then the name of the content. Which means that if the image has no accessible name, the button will lack one as well!
As a last resort, Chrome checks if a title-attribute is present.

Analyzing a button by going through this list can be insightful. It might explain why your title-attribute isn't doing what you thought it would. It might show that an attribute is overriding your intended name.
Note
I usually don't like writing techniques. What I'm writing here is how you can easily check accessible names with the version of Chrome I have right here. Which happens to be version 128. This means there's a factor of ephemerality; the value of this writing might be limited in the (near) future. But I'm writing this anyway. I think the immediate value is there, and part of this will outlive Chrome-versions.

            


Community, corporations and more
2024-09-24T08:59:00Z

                Summer 2023 I made an overview of things I was doing. Summer 2024 is behind us, and now I've got a new list. And my goodness, what a list it is. How much can one person do in a year?


Community
Sharing
Europe
Corporations

Writing, research and advice
Training
Audits and research
And more


What else?
Was it all accessibility?


Retrospectives are so very useful. I know I've done quite a few things, but writing this out? It really puts things in perspective. To keep things a bit structured, I've grouped activities together into subjects.

And yes, I probably picked the worst AI-image I could find.
Community
This goes first, obviously. The Dutch inclusive design & accessibility meetup (Ideally) has had a rough time during the height of the COVID-pandemic. I'm happy to report it's going better! Much thanks to the help of Diede and Thomas (thanks both!) we're building up a regular schedule of meetups again. We're even exploring adding a track of English meetups in and around Amsterdam, with the help of some great new people. Let me know if you want to contribute in any way!
Sharing
There's more on the topic of sharing. A few years ago I wrote Solid Start. It's a method of low effort and high impact accessibility testing that anybody can do. I've applied it a lot this year, and I want to share it even more.

I gave a presentation on the subject at an IAAP EU Event in Paris. Then I gave an extensive workshop at Accessibility Club Summit (where I also contributed to the CfP-jury). I'm currently writing a course on this subject (and another, and introduction to accessibility). Other venues that I've been exploring is a Dutch chapter of the IAAP.

I've also been exploring working together with some other amazing accessibility professionals. I think it would be amazing if we could set up a foundation and improve the position of people with disabilities in the Netherlands.
Europe
If you're not aware yet, June 2025 is when the European Accessibility Act (EAA) comes in effect. That's less than 9 months or 3 quarters for lots of organizations to do lots of work. EN 301 549 is a European standard for accessibility that will play a key role in this.

Last year I spent quite some time making an accessible HTML version of it (instead of a horrible PDF-file currently). I hope setting up a foundation opens a route for me to contribute to this standard even more. I think I'm already the first individual to have an account for their GitLab-repository.
Corporations
With the EAA-deadline coming up, companies are waking up! I've been happy to contribute to several large organizations (think e-commerce, telecommunications, television, sports and such).
Writing, research and advice
Large organizations have lots of needs. I've contributed to knowledge base and brand portals. I've supported people on subjects such as QR codes, dark mode, infinite scroll, responsive tables, HTML validation, (text) alternatives for video, forms, CMSs, apps vs websites, design systems and impact analysis.
Training
I've trained writers, designers, developers, editors, communication teams, billing departments and conversion rate optimization (CRO) specialists. The last one was a particularly interesting subject.

We've discussed everything from designs to websites, and apps to PDFs.
Audits and research
Compliance audits seem to be the bread and butter of accessibility experts. So I've done those, but my range of tools has been much broader!

I've done lots of quick scans. Basically going through Solid Start with a team, and see how much they can improve quickly. I loved doing this. Lots of quick scans give a great impression of the status of accessibility within an organizations. They've also been great as a preparation for trainings! They result in actionable findings, give an impression of broader accessibility, and can make trainings laser-focussed and applied!

As a counterpart, I've also done large sample tests. Extensive dives into entire platforms, and turning generic findings into specific actions and user stories.

Global and specific. Overall and in-depth. I've had lots of fun navigating accessibility at so many levels. I've even done reviews of physical products!
And more
Organizations need personal attention but also strategy and vision. The field is broad and deep. So even with all the tools applied, and meetings with all the disciplines, and all the people I've met, there can always be surprises. I've had the pleasure of regular office hours and joining (internal) communities to uncover some of those!
What else?
I'd say that was quite a lot already. But I did do a few more things. I visited Nationaal Congres Digitale Toegankelijkheid (NCDT). I joined the enjoyable AXSChat. I also gave some in-house talks and live demo's. Contributed to Definition of Done's for easy and continuous accessibility testing. I renewed my certification as the first Web Accessibility Specialist (WAS) in the Netherlands. And yes, I'm pretty sure I didn't mention everything. Apologies for any omissions!
Was it all accessibility?
Pretty much yeah, but I do have some hobbies. I very much enjoyed the garden this year. I've done multiple hikes, including a vacation in Austria. I bought an amazing set of Lego on April 1st that I still haven't finished. Because yeah, it's been quite busy. It probably also didn't help that I shattered my elbow in January.

For the near future, I'm really looking forward to do work as (part of) a foundation. I want to finish my course(s), and really help some large organizations get ready for EAA. Also, ambitious none-work goal: I want to drive a car of my own.
If you made it this far, let me know what you're working on. I enjoy working together!

            


Don't start testing accessibility with a screen reader
2025-02-13T09:57:00Z

                Screen readers are great, and they deserve a lot of love. But let me give you a better option to start testing with.

What is a screen reader?
Somebody might've told you about screen readers. They're wonderful pieces of technology. A screen reader is software (assistive technology) that reads out loud what's visible on a screen. And it also helps people navigate that same screen, without having to see it! Oh, and it can also present output in other ways, like to a braille display!

It's great for people with a visual impairment but people with other disabilities can benefit as well, like various cognitive disabilities.
How does a screen reader work?
Let's assume, as an easy example, you're on a Mac. You're browsing a website using its native browser Safari, and use its native screen reader VoiceOver.

Simplifying some parts, but this is basically what happens:

Whether you tell it to, or on its own, VoiceOver will go through the page. But not like we do. It uses the accessibility API. Browsers have the Document Object Model (DOM), its visual output and the accompanying HTML that we can "inspect". But they also build an entirely different model: the accessibility tree. This is exposed through an API, and assistive technology (like a screen reader) can access this API.
It can navigate all content (no need to make it interactive using tabindex) unless specifically hidden with something like aria-hidden (because this excludes content from the accessibility tree).
It encounters (for example) a heading. Visually, we can see it's a heading. It's likely to be larger, bold and might even have a different colour. Ideally, it's marked up with the appropriate HTML as well, like . This is what we call semantics. HTML is not just a container for content, it's meant to "mark it up" and add semantic value to this content. In this case the heading (role="heading" in ARIA) will be put in the API (AX API specifically) as AXHeading. This is specified in the Core Accessibility API Mappings (core-aam).
This screen reader can pick this up, and communicate it to the user.

In short, the browser puts a website in its API, and assistive technology like a screen reader can access it there.
And they're amazingly useful!
Testing with a screen reader doesn't only test for screen reader users. It can be used to test for image alternatives (WCAG SC 1.1.1). It's a great way to test if proper semantics are used (WCAG SC 1.3.1). Or how about identifying input purpose (WCAG 1.3.5)? And it's also an extremely useful tool for finding out the names, roles and values of elements (WCAG SC 4.1.2)

And that's just a selection. Sometimes it feels like WCAG and screen readers go hand in hand. (And in a way, they might. I've been told a lot of WCAG supports people with visual impairments, and they have a lot of overlap with users of screen readers!)
But don't use them
Yes, I just told you they're great. But I'd advise you to start (!) testing with something else, for various reasons.

Screen readers have their quirks and issues. What works for VoiceOver and Safari on MacOS might not work with Chrome or Firefox on the same OS. Or with JAWS and NVDA on Windows. Or Narrator. Or Edge. Or on phones. Or tablets. You're testing the output and interpretation of a specific tool, in a specific setting with specific settings. You're not testing a specification.
In line with that, it's also useful to know you're testing for a very specific group of people. There's this impression often that accessibility is about "making things work for blind people with screen readers". But there's more to it than that. If you focus on testing with a screen reader, you might reinforce the idea that accessibility is about screen readers. Testing screen readers can cover so much of WCAG, that it makes it very tempting, but the tools we use can also shape our vision on something. (This point awakes the media theorist in me. As Marshall Mcluhan once stated: "we shape our tools and thereafter they shape us". Excuse my tangent!)
This maybe my most important point. Screen readers are extensive tools with lots of settings, options and possibilities. They're so versatile and impressive, that they can be extremely overwhelming! If I would advice 100 people to start testing by using a screen reader, I think at least 99 would drop out very soon after. (And maybe they'd encourage other people to do the same.) Screen readers are too much and not beginner-friendly for this. It's also why I don't tell people interested in accessibility to "just start reading WCAG". Have you seen the size of that, and the language used? It's why I wrote my one-page introduction to accessibility. As people tend to say, accessibility is not accessible.

So what should I do then?
Use a keyboard to test. Keyboards are simple. Pressing the Tab key should take you to every interactive element in an intuitive order. Pressing Shift+Tab should take you the opposite way. If you can reach -and- use every bit of functionality, you’re off to a good start. Every page should also start with a skip link. And people might feel lost when they don’t know where they are. So make sure it is clear which element is focused. That's it. And you can do this with any browser, on any OS. No multiple setups or security clearance needed.

A website that doesn't work with a keyboard will present issues for people with screen readers as well. As screen readers also use the keyboard API to navigate a page. But it will also be an issue for (maybe not surprising) people who use a keyboard. And lots of other groups like people that use switch access, and any other form of technology that makes use of the keyboard API.
Keyboard issues are like the tip of the iceberg. If you find something doesn't work with a keyboard, you're bound to find more coding-related issues. Why do I say that? Because a lot of keyboard issues come from using non-native HTML (people creating custom controls most likely). And these often present more issues than just the ones you find with a keyboard.
And let me repeat, keyboards are simple. Delivering a page? Open a browser, and if everything works, you'll likely go through it with a keyboard in less than 30 seconds. It has such an extremely low barrier for testing. If you've read this blog and have a reason to -not- test with a keyboard, drop into the discord-server and share it please.

But I'll also be honest, and practical. If you already have a screen reader set up and you know how to use it... please do test with a screen reader as well. Just don't scare people off setting them up as some sort of baseline. I didn't have my driving lessons in a Formula 1 car either. I didn't start programming by learning from a bunch of punch cards. And I bet you have your own analogies to add here.
Conclusion
Keyboards are an amazing way to test for accessibility. They have a very low barrier to entry making them an option for many and scaring few. At the same time they help discover tons of issues with little effort (and also give an impression of code quality).

Deliver code? Test it with a keyboard.

            


Tactile indicators for installing and connecting devices
2025-03-05T16:05:00Z

                How do companies make devices accessible for non-visual use? Some thoughts and a question for feedback and experience.


A little bit about tactile indicators
Back to the question

Surface Thunderbolt 4 Dock
Xbox Series X / S


Thoughts

Braille
Icons or pictograms
Simple symbols in a row


Your feedback and experience


The premise might be easily recognisable. (At least for me it is, but that's unfair as I'm the one writing the premise.)

I have a ton of devices all around me. I type this using a computer. The computer is connected to a hub. The hub is connected to all kinds of devices including 2 displays. To my side are multiple printers and scanner. My living room features a television with a game console, audio equipment and various devices. There are devices in my kitchen. Then there's all kinds of network devices throughout the house. And it doesn't stop there. My electric car and charger are devices as well. And what's the common theme for mentioning all these? They all feature plugs, connectors and cables.

For me, a sighted nerd, these are pretty ok to deal with. I've got tubs of cables (really, so many. You don't want to know.) and am familiar with all kinds of connectors and plugs. But if you're less technically inclined, I can imagine it's all quite cryptic. And if you can't see a device, then how do you know what to plug in where? This is an issue for, for example, people who are blind. But I've had my issues with this as well. How often I've had to reach the back of a device and plug something somewhere entirely by feeling around. Cables are always too short. Cabinets too small. Being able to do this without seeing is very valuable!
So here comes the big question; the reason I'm writing this blog. Do you know hardware with tactile indicators for recognising and distinguishing ports? And if so, how have they done this?
A little bit about tactile indicators
I don't have an extensive background in physical accessibility. I assume (hope?) a ton of research has been done in this area already. But here's a bit of what I know.

A common example of tactile indicators is usage on the ground. They're often known as "tactile paving" and include a whole system of patterns for warnings, wayfinding and all kinds of uses.

Another, much smaller, example that might be familiar is braille. This is a tactile writing system based on a grid of 3x2 dots for different characters. People can use a braille rule connected to a computer to use it (and browse the web). There are braille typewriters. Braille can sometimes be found in public transport (like a bus or train) or in an elevator to mark buttons.
Back to the question
To repeat myself:

Do you know hardware with tactile indicators for recognising and distinguishing ports? And if so, how have they done this?

I don't know much about tactile indicators on products. I'm aware of at least 2 products, both by Microsoft.
Surface Thunderbolt 4 Dock
This hub or dock by Microsoft features "Tactile indicators for port identification". This is described as a "Design innovation" on the information page.

Several ports feature small tactile dots above them. For example, the rectangle-ish USB-C ports have 1 tactile dot above it. Likewise, the USB-A ports have 3 dots. And a UTP-port has 2 dots. Other round connectors (like power and audio) don't have dots.
Xbox Series X / S
This game console also features tactile markings. (If you want to see cool and new stuff in the accessibility space, keep track of what happens in gaming!)
Ports are marked with 1 tot 4 tactile dots, or a single tactile stripe.
There's some extensive writing on this innovation on CanIPlayThat.com
Thoughts
Braille
The first thought from many people is probably something "Why not add braille? It's made for tactile writing! Sadly, braille is only read by a very small group of people, so this wouldn't fix the problem for all. Another downside of braille is that it needs 2 dimensions or a small grid. This requires more space for the dots themselves, and space to be able to feel the tactile markings. Then there's the matter of orientation. Upside down, braille would be very confusing! It would also be a very nice bonus if the tactile markings would help nerds like me who don't have a relevant permanent disability, but would like to understand the markings. (I don't would understand them)
Icons or pictograms
What about some sort of tactile image, icon, pictogram, logo or other more complex marking? Notice the word complex. Finger tips have a limited "resolution" when feeling. (There's probably a fancier name for this) Complex imagery runs into this very quickly. There's also way more information in most of these more complex markings than would be needed for the use case.
Simple symbols in a row
This leads us to a solution like that used at Microsoft. What if we use simple symbols like dots, and put them in a row? If there's a reasonable number, it might be harder to distinguish. (Can we feel the difference between 14 and 15 dots easily?) More symbols might be useful, like the dash/stripe! (In my mind, it could be some sort of tactile morse-cde almost)

It sounds like something that could benefit from a global standard. How nice if all USB-C ports would be recognisable in the same way? But I think there's too many different kind of ports and connectors to uniquely identify each in a useful way. So, again, much like Microsoft, I'd say a "local" solution is more useful. One dot for an Xbox does not mean the same thing as one dot on a dock.

Tactile markings can be more like a legenda, that can be understood in combination with a useful manual. A manual could tell you what 1/2/3/4 dots would mean. Especially in combination with different shapes for connectors and ports (round? rectangle?), this should make them recognisable.
Your feedback and experience
Do you know hardware with tactile indicators for recognising and distinguishing ports? And if so, how have they done this?

Do you know of relevant examples? Maybe ISO-standards the are interesting for the question? How would you approach this?
I very much appreciate your feedback on this. Pick any channel you'd like, I'm probably there. We've got Mastodon, Bluesky, LinkedIn and Discord for that. Thanks already, all input is very welcome!

            


I can't read (but I'd like to)
2025-10-15T13:09:00Z

                I have issues with reading books. I find it very hard to read a book. But I used to read quite a lot, and I'd like to get into it again. This is me reaching out, and asking your best tips!
Why don't you read?
For clarity, I'm not illiterate. I'm not dyslexic either. Reading is challenging for me, mostly because of my traumatic brain injury.

When I'm tired.. no, let me rephrase that. I'm usually tired and low on energy. I try to work 40 hours a week as a contractor (which ends up being more than 40 hours) while having a family and a life as well. I find that to be a lot.

So when I do happen to find a chance to read a longer text (and not grab my phone to read messages, and e-mails, and whatever else feels vaguely job-related)... I'm tired. My attention span will be bad. My capacity for processing information will be low, like a brain fog. Letters and text can actually feel like high stimuli. For example, white text on a black background, on my phone screen, can appear to have depth. Text will feel restless. My nystagmus might also play a role in this.

Everything considered, reading is not a nice and relaxing experience.
But you would like to read again?
Yes, please! I used to devour books. Most of my vacation luggage used to be books, and I'd still run out. I'd love to feel that love for books again. To get caught up in stories, and not being able to put a book away.
What will you do?
From what I've read on the subject so far (which, ironically, included some very unreadable sources) I can try the following:

Read fiction. I'll stop trying to force myself to read non-fiction. Maybe when I get back into it.
Read at a lower reading level. Not all my reading has to be literature. I'm thinking maybe a "young adult"-level? Interesting content but no complicated reads.
Use my e-reader. I can adjust things like font-size and text per page to cater to my eyes.
Prefer Dutch over English. English is usually doable, but I might as well give preference to the easier option when given the choice, and when I'm reading for the fun of it!
I won't force myself to finish a book.
I will try and read only one book at a time.

I won't be trying podcasts or audiobooks, sorry. While I'm often tempted, my focus when listening might be even worse than when I'm reading.
And what else?
I don't know? I'm not a reading specialist. I don't usually consider myself vision impaired. I'm asking for tips from those who know more than me!

What can I do to make my attempt at reading more a success? Do you know of any techniques/tools/software or maybe simpler, what books should I definitely read?
Thanks so much for any tips and any feedback. This includes already given feedback on Discord (much appreciated!). You can also join the Discord server or reply on the platform where you read about this blog. Thanks already!

            


Generic impact prioritization lists are an empty promise. We can do better.
2025-11-12T08:18:00Z

                I mean, at first, they seem useful right? Your website gets an accessibility audit. You get a big list of findings to work on.
Where do we start? What should we do first? How do we prioritize? How about we look at the impact on users. Great! You're thinking about users!

And if it means that you're fixing things, then that's great as well! Plenty of audit reports land in drawers unused. Go get that momentum, and start fixing things!
That's the value of prioritization. Like, prioritization in general. When you look closer, you find out it's not quite right.

(This is where, at least in my head, the silly image ties in.)
But if you're getting a WCAG audit done, you might be aiming for compliance. And compliance is a boring binary judgement. You only comply when -everything- is fixed. There's no 50% compliance.
And what about the website; the subject being audited? WCAG SC 1.3.1 does a lot of heavy lifting on a static website. Captions are way more valuable for that essential video on your frontpage, than for that obscure video on a page nobody visits and maybe you shouldn't have in the first place. Or maybe you have videos all over.
And then there's the public that can differ as well. An app that supports communication for when you're non-verbal has a different public than a generic municipality website, or a productivity app.
What's the alternative? It's not very surprising. The solution is something non-generic.
Maybe a WCAG-audit is not the best way to support the needs of users. Get an expert to inspect your website. Let them find the most impactful issues. And then let them support you in fixing them.
(I've been doing this a lot more lately. I think it's a great approach.)
But if you do get an audit, prioritize together with the auditor. Ask your expert about the impact in the context of your website, and possibly your public. Make that report an actionable document instead of a paper weight.

            


New year. New focus. New online presence and communication.
2026-01-02T12:38:00Z

                This is not a new year's resolution. Holidays are just a great period for considerations!
I'm changing some things about how I do things, mostly online. The work field of accessibility is draining. And I think changing these things will make it easier for me to continue this work. I hope they will make things better for others as well.
What I have in mind:

Solid accessibility content is for inklusivo. If I write a blog, a book, a training, or whatever, and it has a focus on accessibility, then it will be part of inklusivo. For context, inklusivo is "my" agency and foundation-in-formation through which I do my accessibility-work. It also means that the "Access Club"-Discord is even less my personal space. It's an open place for anybody to talk about accessibility.
I will share more less-solid content. I think that's the best way to describe the other side of this story. My website will be more of a personal playground again. I'll write more short blogs. Less self-censorship, re-reading and re-writing. They'll probably include more typo's, and will be harder to follow. I'll be much broader in what I share and produce. Topics will likely include more lego, more art, more 3d printing, more gardening, and whatever catches the attention of my neurodiverse mind.

To clarify further, here are some RAQ (Rather Arbitrary Questions):

What if I don't like this? Follow inklusivo.
Where can I do that?

https://www.linkedin.com/company/inklusivo/
https://mastodon.social/@inklusivo
https://inklusivo.bsky.social


Does this sound like a solid financial plan? Probably not.
Sounds like fun! Agreed.
What new stuff do you have in mind?

Updating parts of my website to align with this.
Accessibility courses.
Going to a notary and finally making inklusivo a real foundation.
Moving from my home office into more of an atelier/studio/makerspace
Producing more 3d models for 3d printings, designs for buttons/stickers/t-shirts, whatever pops up in my head. Mainly producing more!
Maybe revive my pixelfed-account and get back into photography.



Welcome to 2026. Welcome to my world. Enjoy, I think it's rather fun place!

            


Looking back on 2025, and looking forward
2026-01-05T08:10:00Z

                It's 2026. Let's join the flood of retrospectives!
2025 was busy, very busy. I was doing very full weeks of freelance accessibility work. That means up to 3 days working for VodafoneZiggo combined with 2 days for the Dutch Design System: NL Design System.

Combine this with short-term assignments, social media, blogging, training, presenting (including NCDT), supporting the Dutch accessibility community through IDEAA11Y, running a Discord server, building for inklusivo, administration, while trying to have a family life with 2 kids who are (at minimum) as bouncy as I am. Listing all this helps me reaffirm: it's been a busy year.

VodafoneZiggo is now down to 1 day a week. I finished working for NL Design System. My agenda feels entirely different now.
If you have something to fill my agenda again: now is the time. I'm available for new assignments. 2025 was busy but I actually enjoy being busy. 👀
If nobody else fills my agenda, I'm certain I will do so myself. This will include catching up on many of the things I was too busy for in 2025. Work in progress is also a free and open course on the foundations of accessibility for inklusivo. I'll take that experience to anouther free and open course about social media. Both inspired by the fact that I see way too inaccessible social media content.

I'm also working in an extensive paid course based on Solid Start. Personally, I'm really looking forward to inhabit our "atelier"-space that's been filled with boxes from moving almost 4 years ago. It's also very much time to turn inklusivo into a real foundation (visiting a notary and whatever it takes).

For more on my personal plans, you could read my previous blog New year. New focus. New online presence and communication. Possible new/old ventures include 3d modeling, 3d printing, photography/art and more sharing than before. I always love more sharing!
Got any ideas, contributions or suggestions? Please let me know. Let's make 2026 even more inclusive!

            


Floating Action Buttons are bad, and what to do instead.
2026-01-21T10:37:00Z

                Some thoughts on Floating Action Buttons as I always run into them, their inefficiency and their inaccessible design.
The Floating Action Button was introduced by Google’s Material Design. To quote Material Design 2:

“A floating action button (FAB) performs the primary, or most common, action on a screen. It appears in front of all screen content, typically as a circular shape with an icon in its center. FABs come in three types: regular, mini, and extended. Only use a FAB if it is the most suitable way to present a screen's primary action.”

The FAB is a floating button, often in the bottom right of the screen, with a function related to the page as a whole.
The placement of the button leads to multiple issues or challenges. Buttons like these are often placed at the end of the code of a page. This means they are very hard to reach with a keyboard. It might need a user to “tab” through an entire page to find out these buttons exist. This makes the practically non-existant.
Which ties in with the second issue: findability in general. Because these buttons are so “out of the way”, they are easy to miss. It’s not just that these buttons have joined advertising on the web, where a certain “blindness” for these elements exists among users. The issue is also that these buttons are not near any content. They exist outside of the context of the page because of their generic floating state.
Interaction, click-through and awareness can increase greatly from weaving the functionality of these buttons into the content of the page.
Instead of a generic floating chat-button, put links or buttons in the page where they are relevant. “Did our links not help you? Please have a conversation with us and we will fix this together.”
Instead of a generic floating feedback-button, put links or buttons in the page where they are relevant. “How did you like our information?” or “How do you rate our support?”
If there is a primary action that warrants a FAB like Google describes, maybe put it at the start of the page. If the action is so important, then making it the first topic and impossible to miss.
This feedback on FABs is not a requirement for WCAG or compliance. It does align with the concept in WCAG to offer information in context like WCAG A Success Criterion 2.4.4 Link Purpose (In Context) and WCAG AAA  Success Criterion 3.3.5 Help.
Addition - 2026-02-11
There is a third issue with FABs: overlapping other content, making that content hard to find, consume and access. This is mostly troublesome on low resolutions and with well-filled footers.

            


Unicorns exist
2026-01-29T09:52:00Z

                Some thoughts on the concept of the "accessibility unicorn".
You might see this online sometimes. A person is looking for accessibility support. They expect the world. The expert they want needs to be able to: develop, design, write, teach, audit, fight fires, plan, strategize, document, remediate, comply, advocate... basically they need to cover every angle the person can come up with. And they need experience. And they need to be certified.
People will reply. You're looking for a unicorn! A what? A mythical creature that doesn't actually exist!

And other people will laugh. It's a witty comparison.
I don't agree though. I don't think it's a problem to search for somebody who can do all that. Partially, that's because I'm biased. I think I can do all that. And when I'm stretched too far, I know the people needed.
But I also disagree, because the issue is not the unicorn. The issue is 3 other factors that usually pair with this.
Factor 1. The unicorn needs to be a specialist in all these things, but the budget for the role is more fitting for a student assignment, internship or something alike. I very much like the saying "pay peanuts, get monkeys". If you want somebody to teach your developers, designers, writers and many more. You want somebody who has something to teach them. You want a person with skills that the people in those roles do not have. You should budget accordingly.
Factor 2. The unicorn needs to do all these things, but they don't get the access, means, resources, whatever to actually do them. Facilitate them. An expert costs more than a student. But an expert is only expensive when you can't utilise what they have to offer.
Factor 3. A unicorn is not a strategy. A strategy would be: we need to depend on one person while we build out our resources, skills and community. We might still need backup when this is in place, but this current stage is temporary.
Unicorns exist. But you have to believe in fairy tales if you think that finding one fixes all your issues.

            


Accessible inline collapsible
2026-02-02T13:18:00Z

                I'm writing an introduction to accessibility for inklusivo. It's like I'm trying to summarize a decade of experience. That's not easy.
One of the challenges is one that I encounter often: how in-depth do I want to go?
Write something in-depth, and it will be too long and extensive for what I have in mind. Write something short, and I might not be explaining enough. Or maybe people find it too superficial.
I do have a glossary on my website, and I'm trying to expand and update a glossary for inklusivo. I think it's already a great step to be able to link to definitions and further resources this way. But linking to other pages breaks up the flow of reading. So for this new creation, I wanted to improve on this!

      See the Pen 
  Accessible inline collapsible by Erik (@erikkroes)
  on CodePen.
      
      
The concept
HTML has a 
 and , AKA the disclosure element, since about 2020. You can display a term in an element, and the element can expand to show details. I could already imagine it: a sentence has a bit of jargon in it and a visitor can chose to expand it as they wish. And all that with a nice native HTML element. And as MDN states: "The contents of the  provide the accessible description for the ." That sounds practical for accessibility as well.
Except the 
-element is so-called flow content. Flow content can not go into a paragraph. And I didn't want to break up reading. I want text to stay intact; like when you add a link to a text. I didn't want to break up the paragraphs.
To the drawing board
Ok. So the native HTML solution was no solution. That's a shame because I do like this combination of elements. Just like I have a weak spot for a nice 
, or .
A 
 would not be useful for a single definition. So I tried to build something with  to mimic . My first idea was something like this (excluding the JavaScript-part):

  Term
  This is the explanation of the term.


There would be a paragraph with a term that needed further explanation. This term would be inside a , and it could expand and show a  with that explanation.  would provide some of the relationship in code, but I would add an aria-describedby as well to strengthen it further.
I say "would" because it didn't work. 
 is also flow content and can't go inside a paragraph. I also found support for  is rather weak. Screen readers don't do much with it. And aria-expanded is not supported . Which is quite logical, as it's not an interactive element.
The solution
What is phrasing content, well supported, and interactive by default? It's our friend 
This is the explanation of the term.

A button that, with the right styling, does not break up the flow of the reader. The content of the button is the accessible name of the button. aria-expanded communicates the state this widget is in. aria-describedby refers to the explanation and gives the button a description.

When activating the button, the  becomes visible to expand on the term in the button.
CSS
.dfn {
  all: unset;
  text-decoration: underline;
}

.dfn::after{
  content: "▲" / "";
  display: inline-block;
  font-size: .9rem;
}

.dfn + span {
  display: block;
  padding: 1.25rem;
  border: 0.0625rem solid;
  background-color: whitesmoke;
  border-radius: .5rem;
}

.dfn[aria-expanded="false"]::after{
  content: "▼" / "";
}

.dfn[aria-expanded="false"] + span {
  display: none;
}

The styling starts with removing all button-styles (beware, this might impact focus styling) and adding an underline for affordance. Then there's the ::after pseudo-element. It shows a little triangle to visually communicate what aria-expanded does in code. The / "" is like alt text, but for pseudo-elements. I'm not even sure what it's called, but it's awesome. If you add an image here, make sure it doesn't get pronounced by screen readers.

display: inline-block; removes the underline from this part. I've experimented with different visual solutions for making clear the widget is interactive, and grouping elements. I found borders, backgrounds and everything else I tried to break up the reading experience too much. In the end, a simple underline and arrow are minimal and functional enough. I assume icon-designers will disagree.

Then we style the span to display as a block (wide) with a bit of spacing, border and background to make it stand apart. We add another ::after for when the widget is in another state, with a different triangle. And we add display: none; to hide the  when the widget is closed.

There is no closed/open-class or anything alike. We hook into aria-expanded to style the different states.
JavaScript
let elementsArray = document.querySelectorAll("button.dfn");

elementsArray.forEach(function(e) {
  e.setAttribute("aria-expanded", "false");
  e.addEventListener("click", () => {      
    e.setAttribute("aria-expanded", e.getAttribute("aria-expanded") === "true" ? "false" : "true");
  });

  e.nextElementSibling.addEventListener('click', () => {      
    let selection = window.getSelection();

    if(selection.toString().length === 0) {
      e.setAttribute("aria-expanded", e.getAttribute("aria-expanded") === "true" ? "false" : "true");
    }
  });
});

The JavaScript is quite minimal as well. When loaded, it finds all widgets. After that, it closes all widgets. When it doesn't load, all widgets stay open. This means it functions like a progressive enhancement. After closing them all, it adds an EventListener to the buttons. When activated, they toggle the aria-expanded-attribute. It toggles between true and false, and does not remove the attribute when false. aria-expanded="false" indicates an element can be opened, which is valuable.

As a "usability-bonus", it adds an EventListener to the s as well. This makes it easier to close once opened. This does require some extra JavaScript. Adding an EventListener for click can make it really hard to select the text. Dragging a mouse to select the text will close the widget. We check if nothing is selected besides our click-event. If no text is selected, we treat it like a regular click.
Conclusion
That's how I built/build an accessible inline collapsible. If you read this shortly after publishing, make sure to check back a week later or so. I bet people will give great feedback and this example will be improved. A live version can be found on codepen.

Curtis Wilcox extended on the codepen with 2 different versions. Both of them use the new popover-attribute turning them into tooltips instead.
This collapsible-pattern has a lot of overlap with a tooltip. Especially when using a popover. Tooltips in the time of WCAG 2.1 by Sarah Higley is a must-read on that topic.
Feedback on this article and code can be given on any of the numerous social media platforms I'm on, including the Access Club Discord-server.

            


Thoughts on people-first language
2026-02-20T10:09:00Z

                I'm writing an introduction to accessibility where I feel like I scrap more than I write. This is a text that didn't make it because it was out of scope.
People-first language
Notice we talk about people with disabilities and not disabled people. This is people-first language.
How a person like to be described varies and can be a matter of personal preference, but people-first language is a good starting point. It focusses on people first, and disability being factors in society. For example, a person that is unable to climb stairs is not disabled until they come into a situation where there are no alternatives to stairs.
The language opposes the classic identity-first language. In this paradigm, the focus is on the person being disabled. It tends to make the person the problem, and makes a disability a part of them. Somebody might prefer this focus on this approach. A person with autism might prefer being called autistic, as it is part of their personality. For example, somebody might prefer to be called an autistic person with asthma.
People with disabilities is clear and accepted language. Avoid euphemisms like "challenged", "differently abled", "handi-capable". There is no shame in having a disability. There is also no special or normal when it comes to disability. Such thoughts lead to othering and are not inclusive. Anybody can be an accident of having a disability.

Partij	Getest adres	Gevonden fouten
VVD	https://www.vvd.nl/	18
D66	https://d66.nl/	11
GroenlinksPvdA	https://groenlinkspvda.nl/	6
PVV	https://www.pvv.nl/	6
CDA	https://www.cda.nl/	15
SP	https://verkiezingen.sp.nl/	23
FvD	https://fvd.nl/	23
PvdD	https://www.partijvoordedieren.nl/	11
CU	https://www.christenunie.nl/	84
Volt	https://voltnederland.org/	18
JA21	https://ja21.nl/	32
SGP	https://sgp.nl/home	23
Denk	https://www.bewegingdenk.nl/	43
50PLUS	https://50pluspartij.nl/	9
BBB	https://boerburgerbeweging.nl/	20
BIJ1	https://bij1.org/	11
Piratenpartij	https://piratenpartij.nl/	9
BVNL	https://bvnl.nl/	12
NSC	https://partijnieuwsociaalcontract.nl/	3
Splinter	https://www.splinterpolitiek.nl/	14

Erik Kroes - Accessibility Consultant | Blog

Why I blog again

Google, please be good

An introduction to Web Monetization

Personal update

The Guide to Accessible Web Components

Semantics, what does it mean?

. This tag is often used for the most important heading (heading 1) on a page. Semantics, what does it mean? The tag or element communicates the intention: this is the main heading, this is what the page is about. If (for example due to an error in the CMS) there is an entire article in a

Semantics, what does it mean?

I made this website with HTML

Your website is history

The value of less

A photographer’s view on alt text

A closer look: "A family evacuated from Afghanistan arrives at Dulles"

Color and contrast, what does it mean?

Inclusion beats optimization

Knowing what to expect (maybe my favorite accessibility principle)

Compose your components

What is accessibility?

The universal focus state

Accessibility, design systems and management.

What you should (not) put inside an anchor link

Aria-roles do very little

Accessibility is not binary

An audit won't solve your issues

. This tag is often used for the most important heading (heading 1) on a page.
`Semantics, what does it mean?`

The tag or element communicates the intention: this is the main heading, this is what the page is about. If (for example due to an error in the CMS) there is an entire article in a