The first thing I noticed when reading his piece is that how he experienced the term is different from how I have. Which means we’re off to a good start. 😃

Like most things, the term [best practice] started off with good intentions. A way to suggest fixes for things which are definitely accessibility barriers, but don't technically fail the Web Content Accessibility Guidelines (WCAG), or whatever standard you're auditing against.

This is not how I have ever seen the term “best practice” used, and I would be as upset as Craig if I did see it used this way.

You cannot fail websites and apps because they don’t meet your personal “best practice”. Best practices to me are techniques that meet the current level of technology and understanding. These techniques are used to meet WCAG success criteria. Most best practices will exceed WCAG.

Let’s look at this concrete code sample:

<span>Your Email:</span>
<input type="email">

This fails several WCAG success criteria, but the most obvious is that the <input> element has no accessible name[^ A 4.1.2 Name, Role, Value violation.], so let’s focus on that.

A technique to make sure that the <input> element has an accessible name is to add an aria-label attribute:

<span>Your Email:</span>
<input aria-label="Your Email:" type="email">

That meets the success criterion, but it is not what I would generally recommend because it has some drawbacks:

• aria-label is often not translated when using in-browser translation.
• The value of aria-label can easily be overlooked when copying and pasting code to generate new, similar interfaces. That’s a future accessibility risk.
• In some screen reader/browser combinations, the aria-label will be announced in the browser language, not in the website language.
• The visual label cannot be clicked to activate the text field.

If I came across code like the example, I would not fail it against the WCAG success criterion, because there is an accessible name[^I might fail it for other reasons and against other SCs.].

Another way to do it is to use aria-labelledby instead:

<span id="emailLabel">Your Email:</span>
<input aria-labelledby="emailLabel" type="email">

This also meets the success criterion. But it also has drawbacks, but arguably fewer:

• The value of aria-labelledby can easily be overlooked when copying and pasting code to generate new, similar interfaces. That’s a future accessibility risk.
• In some screen reader/browser combinations, the aria-labelledby may be announced in the browser language, not in the website language.
• The visual label cannot be clicked to activate the text field.

Lastly, another way is to use the HTML <label> element instead of ARIA:

<label for="emailInput">Your Email:</label>
<input id="emailInput" type="email">

While this solution is still susceptible to copy and paste errors, you can now click on the label to set the focus into the text field, and the label’s text is always read in the page’s language.

So, what’s the best practice?

For me, I would always recommend using the <label> element. So if I find an element without an accessible name, this is my go-to technique. It’s my “best practice” because I think it has the least downsides and is usually not that difficult to implement.

That said, I do not always recommend it. Every so often the component is not relevant enough or the page is unlikely to be translated, so using a band-aid aria-label is good enough.

Frequently I will mention both: The quick fix and my “best practice”.

This gives designers and developers options. Some might find the “best practice” easier to implement, while others will only look at the quick fix.

Recommending best practices is always a double-edged sword: sometimes it can distract and lead to inaction, so the goal is to use them only when they make a noticeable difference for users in the context.

What about non-WCAG accessibility issues?

It happens. The site uses a technique that we think is so bad that it doesn’t meet our high standards.

If you are in accessibility, this should happen every time you do a review. Your standards need to be high to make the differentiation between something that does not meet the minimum requirement and something that just about does.

Grading on a scale from “oops all <div>s” to “this is the most beautiful code I could have written” is important to make the distinction where the line goes.

When an implementation reaches the minimum, but you’re still unhappy with the result, you can add a “Recommendation”. Make clear that it is not a failure but an opportunity for improvement. Ensure that fixing WCAG failures is prioritized over recommendations.

Conclusion

Defining what is the best technique to recommend in a situation is an essential skill for fixing accessibility, a skill that can only be trained by using different techniques and learning about their advantages and disadvantages.

First, where there is “help”, there is “helplessness”. Using the word “help” in the accessibility context implies that disabled people need help from (usually non-disabled) people to accomplish things. While that is sometimes the case, often the same people who “help” are the ones that create accessibility barriers in the first place. You don’t help if you drag a wheelchair and its user up a staircase that you built instead of an elevator. That’s not helping. It’s damage limitation at best. It sounds like we’re doing charity work, but we’re providing concrete technical (and design, and structural) feedback that has societal impact.

Second, typically it is imprecise. Sure, adding an alternative text to an image “helps” screen reader users in the sense that it’s finally accessible. (See point 1.) But I sometimes see sentences like, “Adding an alternative text helps screen readers to convey the image content to their users.”

To me that feels like, “The screen reader would figure it out eventually. It just needs a little help from us!” This is, of course, not what happens. If there is no information, the screen reader cannot convey it.

I often use “enable” or “ensure” instead of the squishy “help” where I can. “Adding alternative text ensures that the content of the image is conveyed to screen reader users.” Or: “Formatting the bold text as headings instead enables users to navigate between headings and use them as reference points for orientation.”

Die Gutachten stammen aus den Jahren 2022 bis 2024 und wurden alle über das Frag-den-Staat-Portal aufgrund des Informationsfreiheitsgesetzes veröffentlicht. Sie zeigen vor allem eines: Obwohl öffentliche Websites und Apps teilweise seit 2002 (also fast ein viertel Jahrhundert) barrierefrei sein müssen, hapert es überall gewaltig an der Umsetzung. Gutachten werden angefertigt, die gefundenen Fehler aber nicht behoben.

Das ist leider ein Zustand, den ich nur allzu gut kenne. Selbst wenn nachgebessert wird, dann nur in Form von Schnellschüssen statt durch ein nachhaltiges barrierefreies Design. Barrierefreiheit verkommt dann zu Insellösungen, die bei neuen Features oder Projekten vergessen werden. Das kostet Steuerzahler viel Geld, das besser in langfristig nachhaltige Seiten und Apps gesteckt werden sollte.

Mehr Informationen zum Portal bei Steady, wo man Caseys bye, bye Barrieren-Projekt auch finanziell unterstützen kann.

(Offenlegung: Ich unterstütze das Projekt seit Februar 2024.)

If you have believed that there is an additional transition period, that is not true. The transition period basically started when the EAA got approved by the European Parliament in April 2019. All EU countries were then required to ensure that the directive is implemented in their laws by June 28, 2022, to be in effect from June 28, 2025.

(Note: Because I have little insight into products covered by the EAA, I will focus on the services, which is the EAA language for websites, online shops, and applications.)

Who needs to fulfill the EAA requirements?

You are under the EAA legislation for services when your audience is in the EU[^and other countries that adapt the same legislation, like Norway] and is customers (instead of businesses). In addition, you are exempt if you are a “microenterprise”, meaning “an enterprise which employs fewer than 10 persons and which has an annual turnover not exceeding EUR 2 million or an annual balance sheet total not exceeding EUR 2 million”.

If you are a microenterprise, try to make your content more accessible anyway. Larger firms will have an advantage over you eventually, as accessible services are often preferred by customers, due to better usability and customization options.

Don’t panic

If you have not met the requirements and are required to do so, you have opened up yourself for potential punishment by the marketing surveillance agencies in the different EU countries you have customers in. There is no way around it: this is serious.

While the fines can be very high (for example, up to EUR 100.000 in Germany), the regulation allows for fixes before a company is sanctioned. This is especially important for first-time violators. The EAA also encourages agencies to support SMEs (“small and medium enterprises” up to EUR 50 million annual turnover) to meet the requirements and not overburden them.

Get support

Unless you have worked on accessibility for a long time, and you know what you are doing, it is highly unlikely that you have the knowledge in-house. To be honest, if you are reading this, you certainly don’t have the knowledge in-house.

This is OK. Before you contact someone and sign a potentially expensive contract, here are some fundamental facts about accessibility you need to understand to make a good decision:

• Accessibility is a process. It’s not a one-time fix or something you can only think about after you have deployed a new feature.
• There are no shortcuts. An accessibility widget or a one-line JavaScript will not make this go away.
• Experience over certification. Many new accessibility professionals have a certificate by the International Association of Accessibility Professionals (IAAP), but understand that these certifications cover fairly fundamental knowledge. In case you’re unsure, ask any professional, certificate or not, what their experience is, especially with projects similar to yours. Understand that Non-Disclosure Agreements (NDAs) might often prevent them from naming specific clients.

The basis of compliance is the EN 301 549 European norm, which includes the Web Content Accessibility Guidelines (WCAG) 2.1 AA. While it is currently not required, looking at WCAG 2.2 AA makes sense to avoid another round of accessibility fixes later. It expands WCAG 2.1 a little, and most sites should meet the new success criteria.

Many accessibility companies will start with an assessment of your service and how well it meets the requirements outlined in EN 301 549. That’s a good start, but without organizational commitment and internal processes, you risk getting into a “develop inaccessible functionality → test → fix functionality” treadmill. We see in many clients that they are fixing some existing functionality while expanding their services with inaccessible functionality at the same time.

You need to avoid this vicious cycle to make your case that you take accessibility serious.

What to do

You have to prove that you are willing to make your service as accessible as possible as quickly as possible. That might help to avoid or reduce fines.

• Commit to releasing only features that are reviewed and tested for accessibility. This will ensure that you do not build up more accessibility debt.
• Fix existing accessibility issues. Plan to test functionality in your service for accessibility step by step and resolve issues or rebuild functionality with accessibility in mind.
• Often re-thinking a feature with accessibility in mind and rebuilding it will be quicker and cheaper than patching accessibility gaps.
• Scope well: Concentrate on the main avenues users use on your site or app first. If you provide an online shopping experience, prioritize the purchase flow over blog posts or other functionality.

A good accessibility coach will guide you through this and help you prioritize what is important, and will also support you with an important additional step of the process:

Documentation

The European Accessibility Act comes with some bureaucracy which requires you to provide accessibility information to users. In most countries this seems to be an on-demand feature, however in some European countries, this takes the form of a public page on your website or inside your app, an Accessibility Statement.

I strongly recommend a public accessibility statement for all sites and applications. Make sure it’s written to inform people with disabilities about the accessibility of your service. If your service is largely inaccessible, communicate goals for making parts of the experience accessible and document when you meet these goals continuously.

You are also required to report accessibility issues with the market surveillance agency when you learn about them. One would assume that those agencies have websites, forms, and procedures ready to review those reports, but it looks like some of them will only be up to speed later this year. While that might allow you a little more time to bring your website or app in order, you should document when you report what to the agency. Overall, it’s your responsibility to demonstrate that you try to conform as best as you can.

Slow, but steady

When you make promises, ensure that you can keep them. Promising too much and then delaying will not only make market surveillance agencies uneasy, but users will also stop trusting you. Plan to take small steps, especially in the beginning. You, designers, and developers need to learn the basics of accessibility first before diving in. Making costly mistakes is easy, especially if the interactions that need fixing are complex.

Think about simplifying your user interface. Consider if a complex interaction pattern is worth putting time in when a simpler form is sufficient. Again, professional help can guide you through the process.

Why did you start blogging in the first place?

When I started blogging two decades ago it was just to share thoughts and interesting posts. I had websites before, but being able to react very immediately to things was intriguing.

What platform are you using to manage your blog and why did you choose it?

I use Kirby, because it is file-based and allows me to use the HTML and CSS that I want to. It is incredibly versatile and I like how it lets you create your own building blocks and site templates from scratch.

Have you blogged on other platforms before?

I used to blog on Textpattern for many, many years, including when I ran Snookerblog. I loved it, but moved to Wordpress in 2014 for its IndieWeb integration. It was a terrible choice for me, and switched to Kirby not soon after. (I just remembered that I ran Jekyll and 11ty for a bit, and blogs with build steps are just not for me.)

How do you write your posts? For example, in a local editing tool, or in a panel / dashboard that’s part of your blog?

It really depends on how serious the article or post is. If it is longer form, I tend to grab iA Writer or Ulysses for structure and then move it over to the Kirby panel. But for posts like this one, I just write it in the Kirby panel. It’s great on desktop and acceptable on iPad and iPhone.

When do you feel most inspired to write?

I rarely do feel inspired to write these days. My “day job” involves a fair bit of writing, so doing additional writing feels like even more work. That said, I get motivated when I figure out new ways to explain something and occasionally when I’m angry.

Do you publish immediately after writing, or do you let it simmer a bit as a draft?

I have plenty of drafts, they rarely get published. Usually, I discover that I have already written the article or the act of writing it down reveals that the topic was not worth writing about at all. I use my blog as a way to rubber-duck ideas. If I like an article and I have the feeling it is reasonably well written, it goes live immediately.

What are you generally interested in writing about?

Mostly about web accessibility, including the societal and educational problems that lead us to create inaccessible software and products.

Who are you writing for?

I don’t write for anyone in particular, but my articles skew technical, and so it’s probably mostly developers. And of course for my supporters on Steady:

What’s your favorite post on your blog?

My recent post about WCAG 1.4.11 Non-Text Contrast is probably my favorite because I researched it really well and made numerous examples.

Any future plans for your blog? Maybe a redesign, a move to another platform, or adding a new feature?

I would love to redesign the blog, but I don’t really have time/energy at the moment. Plus, I’m reasonably happy with the look. I would like to restart taking comments eventually. There are always things that could be done differently.

Tag ’em

I‘ll try not to put to-do items on other people’s lists, so if you want to take these question and answer them, please do! And if not, I leave you with a Doctor Who quote:

The blossomiest blossom.
That’s the only sad thing.
I want to know what happens next.
Right then, Doctor-whoever-I’m-about-to-be.
Tag. You’re it.

I added some things: A web page lists the URLs now together with the dates they have been picked for. This meant I had to give the page a history of all previously generated URLs. In the first version of the page, it only served as a random generator of a WAI URL and also, basically, only as an API – returning just the URL as a text string. So every time I accessed the URL, the response was different.

To change the design, I now save every URL into a JSON file, together with the date as a key. This allows me to check if a key is present for the current day and return that URL, or generate a URL if it is not. The first time the wai-a-day.yatil.net domain is accessed every day, the randomizer picks a URL and saves it to the JSON file.

I have used this way of a key/value storage quite often, and it is quick and just works. There are probably quicker ways to do the lookup that does not require as much reading from disk, but to be honest, I cross that bridge when I get to it after the JSON files gets many, many megabytes large.

What I don’t like is the monotony that the repeated generic social media previews on the WAI A Day Mastodon account bring. Sure, this might not be a big deal in the grand scheme of things, but because I only have the URLs and I cannot produce more meaningful content for the toots posts, the social media previews are distracting. I wonder if I could parse the social graph texts myself and return a more meaningful, generated image – like I do for this blog – and embed this as an image in the post. But then that would not be clickable to the resource.

Proxying all links through the WAI A Day site was a consideration, but cool URIs don’t change. While I have no problem with the WAI A Day page going away, I’d like all fragments of its existence to work independently with the original URLs.

The feedback from the community has been great, 65 followers on Mastodon and 20 on (reluctantly) Bluesky is not a huge number, but it’s a start. I wonder if I can use the data elsewhere, too. Would a Slack integration be useful? (Boo! Walled gardens!)

I want to highlight that the randomizer did a good job picking interesting pages in the first seven days (and I did a good job narrowing the options down for it):

• 2025-03-08: Planning and Managing: Initiate
  • This resource gives organizations hints on how to start making concrete accessibility changes that last. You couldn’t imagine a better first link.
• 2025-03-09: User Agent Accessibility Guidelines (UAAG) Overview
  • W3C has many standards, this is the one about Browsers and what they should do for accessibility. A little niche, but that’s why it’s random.
• 2025-03-10: Overview of “Web Accessibility for Older Users: A Literature Review”
  • If I had seen this in the dataset, I probably would have removed it from the list, as it is more of a support document to another document, and also last updated in 2008. Still relevant, though.
• 2025-03-11: Resources for Policy Makers
  • I debated letting these meta-pages in there, but seeing it here after a niche page, having a broad one feels right.
• 2025-03-12: Cognitive Accessibility Objective: Use Clear and Understandable Content
  • The supplemental guidance of how WCAG relates to cognitive disabilities is great, so I’m happy that it is included in the list! (I’m less happy that these pages use a separate navigation pattern from the main WAI site, I find it confusing.)
• 2025-03-13: Accessibility Principles
  • This page is frequently the first I guide people new to accessibility to, as it is a really nice overview of the guiding principles.
• 2025-03-14: Zoom Levels - Easy Checks
  • This is part of the relatively new draft Easy Checks, and I like it. Learn how to test zoom.

I hope the radomizer keeps picking this well. Don’t forget that you can support this and all my other indy projects on Steady. Or subscribe to the newsletter.

My grandiose idea would have been with custom promotional text that summarizes the resource and maybe give some more context.

Suffice to say, we never followed through for a few different reasons. The priorities just didn’t align. It happens, but I still liked the idea. So just five years after leaving W3C, I created my own low-effort version of the idea.

It’s called WAI A Day, and it highlights a WAI resource every day.

Where to follow?

You can follow the Mastodon account @WAI_A_Day@yatil.social and the account will post a random WAI resource every day at 17:00 Central European Time.

There is also a Bluesky mirror, but if you can, use the open social network Mastodon instead.

Caveats

The list of URLs that the script choses from is filtered from the sitemap.xml file of the WAI sub site. I wasn’t happy with some of the URLs that are in there, so I decided to filter out some URLs, mainly:

• Translations (the account only posts English resources for now)
• News (they are often outdated and not suitable for this kind of account)
• Tests for ARIA features
• Example pages
• Some sub-pages that I did not feel were useful to be featured out of context

I just auto-post the URLs and the social media preview of Mastodon does the rest. Unfortunately, some of those previews are more useful and others are less useful.

In addition, that list does not contain any specifications or any Understanding documents of W3C. I hope to add them to the list at a later date, but I could also see those documents overwhelm the other resources.

Code

The code for inspection and the created URL list can be inspected on my Codeberg profile.

Thanks

My deepest thanks go to my supporters on Steady who allow me to invest time into projects like this.

This is a difficult text to write and as I start, I realize that I don’t know where this is going, so please excuse me if it is even more meandering than usual.

Let’s talk about the disconnect within the accessibility scene/industry/community[^ Oh, more disconnects!] and about the stampede of elephants in the room. Last week, Deque used their free axe-con marketing event[^ There are genuinely great talks featured, and it is a great resource to the community, but the company wouldn’t do it if they would not expect publicity from it – which is a fair deal.] to announce the vision of getting to 100% automated accessibility (by volume) across all disciplines within the next 10 years. This would be possible with “AI”.

The backlash during the keynote was swift and forceful. I’m not sure how this was not anticipated. Axe-con is still a conference considered part of the accessibility community, so the message to replace genuine human testing and evaluation with “AI” could never land with that audience. But it also wasn’t made for that audience[^ Sorry, but if your script says, “Your work isn’t just following the AI revolution, it is enabling it.” that’s just another way of saying “We will take your work and productize it and sell it.”].

I don’t want to replicate the slide, but there is a slide that shows 2024 as 57% of automation, and 2025 as 100% automation, despite saying later that that’s somehow a 10-year vision. The presenter also says to get to 100% “or as close so it doesn’t really matter”, and that is an interesting phrase.

Because accessibility happens in these margins. “These few users and use cases don’t matter” is something I still hear occasionally. Recently, a fairly large online shop has introduced screen reader detection in their app to see if screen reader users are actually using their app – which is not very screen reader friendly. These tactics are used to reduce the need to make technology accessible.

The reality is: These percentages, hundredths of percentages, that is what web accessibility people should care about. This is where it matters. Promising 100% coverage or close to it, siphoning funds off real accessibility changes, will lock out people quickly.

And then there is the other side of the coin of being a consultant for accessibility. It’s not (just) about crossing t’s and dotting i’s to ensure conformance, it is about teaching designers, developers, project managers, and beyond the importance of accessibility and how to use it to make more inclusive and less ableist decisions that lead to better outcomes.

We know that “AI” impacts critical thinking negatively. This is an inherent threat to accessibility in particular but also to human society eventually. Mindlessly copying and paste corrections from an “AI” might make you feel more productive, but what starts as automation in one section (for testers in the case of accessibility testing aided with “AI”) becomes worse productivity somewhere else. For example, designers that don’t understand how to create accessible color pallets need to re-do them over and over again because “AI says no”, but they might not understand why. The same goes for programmers who will correct their code and never learn to do it correctly. If the “AI” is broken, or the problem is new, they don’t know how to deal with it. And sometimes the “AI” might just generate nonsense[^ “hallucination”] and the critical thinking of determining if it is right or wrong is absent.

I think the misstep in tone in any presentation, especially with “AI”, is to not acknowledge the threats that concern disabled people and the community that supports them. Dismantling the state apparatus in the US that has historically ensured that disabled people get their rights, the thread of war, massive cuts to health care, the attempts to treat disabled people as second-class people.

Not acknowledging these changes and then framing the European Accessibility Act (EAA) as an excellent business opportunity that will need more people to work on accessibility just shows how far apart the values of some accessibility companies are in comparison to the people they work with. Also, I’ve seen a fair share of people on LinkedIn who have moved on from Deque over the last year, maybe the need for “AI” would be lessened if those employees were kept?

As you might have noticed, I don’t mention the names of the presenters of the Deque session because while I think they believe what they say, their objectives, their values are company objectives and values. As a company, it is a straightforward thought to say “clients/stakeholders/investors want to hear about AI, let’s talk about AI”.

But in accessibility that does not work. I, personally, believe that it works nowhere. And even if “AI” was working and universally fixing ableist outcomes of human processes to be technically accessible, my values tell me that we only put icing on an ableist mud cake.

It might quack like a cake, walk like a cake, and look like a cake, but it’s still muddy underneath it. It also would make accessibility something with a price tag, something that can be saved if politics is not defending accessibility – like what happens in the US right now. A developer who has learned to produce good, accessible code will write it whether it is mandated or not. When you switch off an “AI Agent”, you’re left with nothing permanent and/or a decrease in accessibility in the future.

There is no magic wand to make accessibility happen, other than hiring disabled people and include them in every step, in every decision. You want “100% AI accessibility”, try the Accessibility Intelligence of actual disabled people.

There are use cases where “AI” tools can actually be helpful. In real-world situations where there is no description available, a picture description can help with orientation or finding things. When there is no alternative text provided, users can use it themselves to identify the photo. Then at least they are aware of possible mistakes. Providing transcripts in situations where there is no time or budget to have them done professionally[^ Apparently Deque thinks automated live transcriptions are good enough for an accessibility conference, and I vehemently disagree. The transcripts are barely understandable. They also sometimes transcribe “Deque” as “TC”. The captions appear to be much better.] can be a stopgap.

My values are people-based, are community-based, are society-based. I think when we learn from each other’s experiences, we will grow as humanity, and we will grow our humanity. I know that it doesn’t look like this at the moment, but no societal growth spurt happens without backlash or setbacks.

Accessibility is difficult, working in an ableist society is difficult. Realizing that ableism runs wide in the accessibility community hurts[^ Explicit props to Deque for making this a COVID/Influenza competent experience by holding it online. I also think this conference is much more accessible cognitively because you can watch the videos on your own time and from the comfort of your own home. Most conferences, accessibility or otherwise, have given up these crucial aspects of accessibility]. This is a chance to think about our own values and how we apply them to our jobs. For me, supporting people to experience all their human rights equally is a fundamental value. Not only that, but I think inaccessibility violates people’s dignity.

I, and probably everyone in the accessibility industry, could be in a better paying, less stressful, less occasionally antagonistic role with our skill set. Really good accessibility professionals (and yes, I butter my own bread here – deal with it) have skills that translate into all different situations because that’s what you need to be good at your job. You need to be a designer, a developer, a manager, a teacher, a decider, a reader of specifications, a shoulder to lean on, a resilient punching bag at times. Accessibility is a holistic discipline, so to be a specialist here, you also have to be a generalist in most other disciplines and a specialist in some.

It’s a tough gig, and we’re squeezed between our own goals and the compromises we have to agree to daily.

The reality is that most of us have so high values that we are bound to fail in an ableist society. “AI” won’t change that. What it will do, similarly to Overlays, is that it devalues accessibility work by decoupling it from the actual humans needed to do the work and from the actual humans who need the work to be done. (Especially in accessibility, there’s significant overlap between those groups.) We accept that the platonic ideal of accessibility is unreachable in this ableist society, but it doesn’t stop us to push the Overton window into a more accessible place. That acceptance is mostly self-protection and self-preservation. Without it, we would have a binary choice of giving up or pushing for perfection, but that’s just not how the world works. I know that this difference between what we want to do and what we can do is a huge burden, especially for people who are new to this, and there are few support structures in place to help to deal with this stress.

Telling people that accessibility “so close to 100% in a way that it doesn’t matter” is possible with “AI” is a gut punch. It undermines the expertise and the versatility of the profession. It makes accessibility a technological problem, but it is a human problem.

How do we know? “Accessibility will be solved by technology in 10 years” is progressing in the same rate as is “AI” in general and fusion power. It’s always around the corner. And then it never is.

What this causes is deferral and loss of knowledge. We already have a significant gap between juniors and seniors and no clear paths how people can train up to be better equipped with testing and fixing accessibility. That’s the challenge we already have and by declaring accessibility a “100%” solved problem, we’re losing the interest from new juniors in the field and devalue the knowledge of us who do this for a long time.

Do I think that I, someone who does this for over 15 years of in-depth experience, should not do the chores of writing up simple alternative text issues? Sure! But I also know that this is a great way to get started for people new to it and then step-by-step broaden their experience. In addition, what I write up for clients does not matter that much, but how I write it up, how I inspire them, how I engage them to address issues. Communicate where the main blockers for disabled people are, and ensuring that they don’t focus on small issues that are not that important in context.

The reality is that my values, my goals for my job are different from those of big accessibility companies. For a company, dependence is important. That creates long-lasting clients, and that brings in the money. While I want and need to pay my bills, earning money is not my goal because there will always be enough work for me. I look forward to – and fondly back on – every instance where clients told me that they now have accessibility under control. Just this year, a long-term client project halved their hours with me, not because the coaching wasn’t useful, but because they have now more knowledge and understanding and don’t need to rely on me as much. This is wonderful.

Overall, it’s totally fine to have different values and different goals. The disconnect exists when you try to convince me that your values are also my values. They are not.

Some interesting axe-con talks

Here are some axe-con talks that caught my eyes and that you should check out[^ You can make your own decision on what the choices say about my current state 😬]. I did not watch any of them before I wrote above because I could not make time for it yet.

• Cyborg Concerns & Disability Services by Dr. Ashley Shew
• No, Seriously, F*ck Engagement: Building a More Human Web (Content Warning) by David Dylan Thomas
• Burnout, Bullsh*t, and Broken Systems: Surviving Digital Accessibility in the Trenches (Content Warning) by Kevin Andrews
• It is designed to break your heart: Cultivating a harm reduction mindset as an accessibility practitioner (Content Warning) by Eric Bailey

While working for a client the other day, I found that Polypane[^ Affiliate link.], which is excellent in locating accessibility issues, showed elements with tabindex="-1" as focusable in the Focus Order section of the Outline tool.

I contacted Kilian to see why that was happening, and he pointed me to the Accessibility Tree, which showed the element as focusable, too.

This is where I understood that there was a mix-up between two concepts: Sequentially focusable and programmatically focusable elements. The former are elements that can be reached with the tab key. Mixing these concepts is easy, as we use “focusable” because it is short and because the concepts are somewhat related. But for accessibility testing and understanding why we see certain behavior, understanding the difference is important.

What are sequentially focusable elements?

For elements without a tabindex attribute, the HTML spec has the following list of sequentially focusable elements:

• a elements that have an href attribute
• button elements
• input elements whose type attribute are not in the Hidden state
• select elements
• textarea elements
• summary elements that are the first summary element child of a details element
• Elements with a draggable attribute set, if that would enable the user agent to allow the user to begin drag operations for those elements without the use of a pointing device
• Editing hosts
• Navigable containers

In addition, elements with a tabindex attribute of 0 are also part of the sequentially focusable elements.

Elements with a positive tabindex attribute are also part of the sequentially focusable elements, but reorder the sequence[^ Note that positive tabindex values are always sorted to the top of the sequence. If three links anywhere on the page have the tabindex values of 7, 42, and 147 respectively, they would be sorted to the top of the sequence as first, second, and third item in the sequence.]. There are almost no circumstances that warrant positive tabindex values[^ In my opinion, positive tabindex values cause more harm than benefit, HTML should deprecate them and treat them like tabindex="0"].

Note: On macOS/Safari the tab-focusable elements are different from on other operating systems due to historical reasons. To test with a comparable experience, follow Browser keyboard navigation in macOS.

What are programmatically focusable elements?

Programmatically focusable elements not (only) receive the focus when the user presses the tab key, but can (in addition or exclusively) receive the focus through JavaScript’s focus() function or because a fragment identifier points at the element with a corresponding id.

All sequentially focusable elements can also receive the focus programmatically. In addition, a negative integer[^ While any negative integer is allowed, in practice -1 is usually the go-to value as other negative integer values have no different functionality.] value for the tabindex attribute makes an element a programmatically focusable area but does not add the element to the sequentially focusable elements.

Programmatically focusable elements are useful when you need to direct users to a specific place in a website or app, especially after actions. A table of content might want to set the focus on the heading (a non-sequentially-focusable element) when using a skip link. Adding a negative tabindex to the heading makes it possible.

While programmatically focused, the focused element is treated as being the focus sequence as if its tabindex value was 0. It’s inserted in the sequence and tab will go to the next item in the sequence.

In addition, negative tabindex values also remove sequentially focusable elements from the sequence!

A link with a negative tabindex cannot be reached with the tab key, but most assistive technologies work around it. Screen readers, for example, can set “screen reader focus”[^ And you really thought we had only two things that we call focus here? Oh, sweet summer child!] to such a link when using arrow key navigation.

Some UI elements like tabs can use negative tabindex and programmatically assigned focus to control the interaction.

Demo

Here’s a demo with different permutations of elements and tabindex values:

What are “In Brief” sections?

“In Brief” sections are information that has been added to every single WCAG Success Criterion Understanding page. They contain three bits of information: The goal of the success criterion, what to do to reach that goal, and why it is important to not violate the success criterion. Take for example the “In Brief” section for SC 1.3.1 Info and Relationships. First, the full Success Criterion as a reminder:

And here is the “In Brief” section from the Understanding document[^ In contrast to the actual understanding document, I use an unordered list instead of a description list.]:

• Goal: Information about content structure is available to more people.
• What to do: Use code to reinforce relationships and information conveyed through presentation.
• Why it's important: People can adapt the presentation to suit their needs while preserving the original meaning.

What is the goal of the “In Brief” sections?

The goal is to give people who are new to WCAG an easier to understand way to know what a Success Criterion is about. I think that is a great goal. The second goal stated in Shawn Lawton Henry’s comment on GitHub is to focus on disabled people’s experiences instead of (purely) conformance.

I think those are great goals.

Why I don’t like the current implementation of “In Brief” sections

I have multiple problems with the “In Brief” section as they are currently implemented. I hope some of them can be addressed, but I don’t hold my breath.

1. Position/Design

For some time now, the “In Brief” sections are displayed between the Success Criterion title (and page heading) and the actual text of the success criterion (and non-normative notes quoted from WCAG).

In the WCAG 2.1 version[^ Please ask the AGWG about the existing of different explainer documents for normative requirements which have exactly the same wording.] of the Understanding documents, the “In Brief” section was only added to a few SCs. It was put underneath the Success Criterion boxes, and at least on desktop browsers, it was clear that the first part of the page was the Success Criterion and then the explanation followed.

I always thought that the visual distinction was a bit confusing, but at least it felt clear to me that the top had the success criterion and the bottom explains it.

Side note: While the pages always included the normative terms from the WCAG glossary, a reader might not identify them as such. They have also been renamed to “Key Terms” and collapsed as a section, further de-emphasizing their importance.

With WCAG 2.2, the “In Brief” sections were initially kept underneath the success criteria. But then got promoted to the most prominent place on the page, directly underneath the main heading.

The technically normative Success Criterion name is now followed by non-normative text, followed by the SC box (which contains the normative text of the SC and quotes non-normative notes), followed by explanatory text until the “Key Terms” expand/collapse which content itself is quoted normative content.

I’ve visualized the normative/non-normative balance in the following screenshot:

Compare this to a screenshot with the “In Brief” and “Success Criterion (SC)” box switched:

I would even argue to integrate the heading and the SC text even better, getting rid of the SC box and maybe letting go of the notes altogether, since they are basically mini-understandings inside the specification.

Now, this would not be a big deal, if it was just a little more confusing to me, but there are reports of other people finding the Understanding documents harder to use. I have been quoted “In Brief” information as if it were normative text by clients. I opened an issue in June, and another one was opened in July.

One seemingly helpful suggestion was to link to the Success Criterion box directly (Example) by adding #success-criterion to the URLs that I share. But that hides the name of the Success Criterion and its number[^ Why are the numbers so small, btw?] and is disorienting. It also removes the branding from the link which is important to say “See, I’m not guessing, there is official information about this.” and helps with credibility.

2. Content/Information

Let’s talk about the actual content of the “In Brief” sections. Let me re-quote the 1.3.1 Info and Relationships one for you:

• Goal: Information about content structure is available to more people.
• What to do: Use code to reinforce relationships and information conveyed through presentation.
• Why it's important: People can adapt the presentation to suit their needs while preserving the original meaning.

I picked this SC basically at random. This is not a good explanation of why 1.3.1 Info and Relationships is important at all, or how to do it. It uses jargon language that is also vague. It also does not cover the whole SC.

And this is a pretty easy to explain success criterion:

Information that is clear for people who can see the screen must be either available in text or in (HTML) code to allow assistive technologies to read this information. It also allows for adaption of the information to user’s needs. A heading must not only look like a heading, but be marked up like one. Screen reader users can then navigate from heading to heading, low vision users might decide to increase the size of headings or use specific colors to make headings easier to find.

Is this longer than the “In Brief” section? Yes, but it is also clearer for anyone reading it. Not only does it help to use full sentences, it also uses concrete examples and little jargon. This can be word-smithed for sure, it’s literally a first draft.

I also think that the goal of putting the focus on disabled people’s lived experiences is not really met with the “In Brief” as it is. 1.3.1 above talks about “more people” and that “people can adapt”. Disabilities are not even mentioned in many “In Brief” sections. Sometimes assistive technologies are used in the abstract without concrete use cases. SC 1.3.4 Orientation (AA)’s “In Brief” does a good job with its “Why it’s important” sentence: “Wheelchair users and others may have devices mounted in a fixed orientation.” Expand it to “Wheelchair users and others may have devices mounted in a fixed position, so allow that your content can be viewed in both, portrait and landscape orientation.”

3. Audience

And that brings me to the third point: What is the audience of the Understanding documents? For years, the audience was people who had the need to distinguish between pass and fail states. But they also helped clients to understand why we would fail something.

Having the SC and then supporting it with examples and different fail/pass cases is incredibly useful. It was never the most clear and best tool for the job, but it worked. Practitioners included links to it in audit reports and clients found it useful.

Since the change to “In Brief”-first listing, I had colleagues and clients confused. People share user styles to hide the section.

The Understanding documents try to be all things to all people, but they must be concise and helpful for conformance.

What to do?

Having an overview for users who are new to WCAG without all the baggage of the Understanding documents is a great idea. And it already exists somewhat in the What's New in WCAG 2.1 and What's New in WCAG 2.2 resources, which are specifically created for people new to WCAG. (Here I also prefer the WCAG 2.1 approach of showing the Success Criteria first and then explaining it.)

In any case, WCAG 2 and its Understanding documents are not the right place to start – How People with Disabilities Use the Web is a great resource to understand why accessibility is so multi-faceted. It’s a much better start. And yes, integrating these resources in the Understanding, or at least linking to them, is useful for many people.

I’m all for making the Understanding documents easier to understand, but adding more content is not the best way to go about. Every Understanding page has an intent section that already does a good job of explaining what the SC does:

The intent of this Success Criterion is to ensure that information and relationships that are implied by visual or auditory formatting are preserved when the presentation format changes. For example, the presentation format changes when the content is read by a screen reader or when a user style sheet is substituted for the style sheet provided by the author.

I think it’s clear that some de-jargoning and using simpler sentence structure would meet the goal of making the Understanding pages easier to understand without sacrificing their utility.

I think explaining WCAG success criteria in brief is not a good proposition in the first place. The Success Criteria are of varying complexity, but they all deserve that interested people read and analyze them. Sure, the approach to actually explaining WCAG SCs in detail (like I did for 1.4.11 Non-Text Contrast (User Interface Components) recently) will take them more time, but they also will have understood more of the nuance of the SC. There I start with rewriting the relevant part of the SC into more prose and then analyzing every part of the wording. This matters because it helps to form an understanding of how WCAG works.

Other examples

SC1.2.2 Captions (Prerecorded)

Several days ago, I posted my problems with the “In Brief” of SC 1.2.2 Captions (Prerecorded) (A) on Mastodon. It reads:

• Goal: Videos can be played with captions.
• What to do: Provide synchronized text for audio content in existing videos.
• Why it's important: People who are deaf or hard of hearing can understand audio in videos.

Here, I especially don’t like that it says, “People who are deaf or hard of hearing can understand audio in videos.” The whole SC is about an alternative for the audio in videos. It is about making information in the audio of videos perceivable[^ In my experience, mixing perceivable and understandable when explaining WCAG concepts can lead to confusion, too. I try my best to use “perceivable” when explaining SCs/issues in the Perceivable principle, and reserve “understand” for the Understanding principle.] for d/Deaf and hard of hearing individuals.

In addition, “synchronized text” is more jargon than captions or subtitles. I can understand that you don’t want to repeat “captions” in all three sentences. But the uniformity of the advice is a self-afflicted constraint. “Videos can be played with captions” sounds a little like a technical problem, however, providing captions for media needs planning, some design decisions, and the infrastructure to make it work.

SC 2.5.8 Target Size (Minimum) and 2.5.5 Target Size (Enhanced)

For SC 2.5.8 Target Size (Minimum) (AA), the “In Brief” section reads (as pointed out on Mastodon, too):

• Goal: Make controls easier to activate.
• What to do: Ensure targets meet a minimum size or have sufficient spacing around them.
• Why it's important: Some people with physical impairments cannot click small buttons that are close together.

For SC 2.5.5 Target Size (Enhanced) (AAA), the “In Brief” section reads:

• Goal: Controls can be operated more easily, especially on touch screens.
• What to do: Make custom targets at least 44 by 44 pixels.
• Why it's important: Some people cannot tap small objects.

Again it uses jargon, “targets”, “minimum size”, “sufficient spacing”. The enhanced even says it applies to “custom targets”, something that is not defined or explained anywhere. And instead of naming disabilities that are concrete, it’s “some peopled” again. People with hand tremors or spasms are good examples of people who depend on large targets, whether they click or tap.

Minimum even names an exception as part of the “In Brief” which I’m not a fan of. Exceptions are compromises, not part of the guidance that I would expect on such an intro-level.

Updates

• September 8th, 2024: Added second other example.

The “Understanding Levels of Conformance” section in the Understanding documents explains which considerations contributed to the decision for each criterion (paraphrased):

• Is this SC essential for access overall?
• Can the SC be achieved by all websites and apps?
• How easy is it to learn or address the issues that this SC uncovers?
• Will meeting the SC require changes to the design or functionality of the site or app?
• Is it possible to work around requirements?

Importantly, not all criteria apply to all Success Criteria. But here are some examples:

• 2.1.1 Keyboard is Level A despite the effort it can take to implement keyboard navigation and the occasional impact on design and functionality because keyboard access is absolutely fundamental for accessibility. There are very limited workarounds when keyboard access is unavailable.
• 1.4.5 Images of Text is Level AA because it can change the design, it can sometimes be difficult to change from an textual image to “real text”, depending on the tools used, and text alternatives (and more recently OCR) can be valid workarounds.
• 1.2.6 Sign Language (Prerecorded) is Level AAA because recording and embedding sign language information can be a significant effort and is probably unrealistic for many websites (for example news sites that are frequently updated). Most sign language users can also perceive written information.

While this is easy enough to do when creating the SCs, the levels lose their usefulness when clients try to use them as signifiers of what is more important. Because the reality is: everything on the level you want to conform to is equally critical.

The Levels are also the result of a political discussion during the creation of WCAG, there is some amount of back and forth that happens when new SCs are introduced, and the group needs to come to a consensus. A W3C member might feel strongly that an SC is so difficult to implement that it should be Level AAA. The group has only two options: Try to change the SC until the member agrees to move it to a lower level, or accept the AAA designation.

In practice, it makes almost no difference for disabled people in which order issues are fixed, with the following exception:

Non-interference SCs are four SCs that are listed in WCAG that create barriers so significant, that they affect the ability to use the page overall. Those SCs are (order as in WCAG):

• 1.4.2 Audio Control
• 2.1.2 No Keyboard Trap
• 2.3.1 Three Flashes or Below Threshold
• 2.2.2 Pause, Stop, Hide

So, if anything, failures concerning those SCs should have preference over others. As for the A/AA distinction, it’s mostly academic: Most would agree that conforming only to Level A is not good enough to ensure that most disabled users have basic access. Level AA (which means meeting all Level A and AA criteria) is widely considered the absolute baseline. And that includes laws and policies around the world.

In my final talk, “Web Accessibility is broken. It’s time to fix it.”, I proposed gentle WCAG reform (instead of the W3CAG revolution). Video here. My suggestions included combining the A and AA Levels.

AAA Level SCs should be checked if they are more achievable today than when they were introduced and either imported into the standard (making them A/AA) or exported into modules that individual websites could then choose to conform to.

For the above-mentioned Sign Language Success Criterion, websites would conform to WCAG 2.5+Sign Language. The modules could be listed in the accessibility statement of the site, and users who need the information would know better which features they could expect.

This approach would also allow getting rid of some redundant success criteria: 1.2.3 Audio Description or Media Alternative (Prerecorded) (Level A) requires a audio description or a transcript with described audio, while 1.2.5 Audio Description (Prerecorded) (Level AA) requires audio description, essentially removing the option to use a descriptive transcript instead.

Similarly, another contested issue could be simplified: 3.3.2 Labels or Instructions (Level A) technically only requires that labels need to be present, 2.4.6 Headings and Labels (Level AA) requires that the labels are also actually descriptive. In practice, because most conformance is aiming at Level AA anyway, labels need to be descriptive[^ And yes, it’s a good question if the distinction of these two SCs is really useful…].

In my trainings, I only teach levels as conformance levels and not really elaborate on individual SCs Level rating. When I point out what the Conformance Levels do, my short, easy to learn explanation is:

• A: Removes many barriers for many disabled people.
• AA: Removes most barriers for most disabled people.
• AAA: Removes additional barriers.

It’s not the most clear and comprehensive way to phrase it. But it gives student’s enough to not worry about individual levels. It also helps explain why A conformance is not enough, and AA conformance does not mean that your website/app is “accessible”.

Note: I think this article applies to all kinds of accessibility audits, whether they are called “review” or “check” or “audit”.

What’s this all about?

Audit reports can be very long with dozens of issues and how to solve them. They include simple failures like missing alternative texts or single unreachable buttons, as well as more fundamental issues like a color scheme that produces low-contrast text or UI elements that are difficult to make accessible.

An example of the latter is what I call “overloading UI elements”: Modern search fields that you see at the top of many websites, especially in e-commerce, are often overloaded. They look like a simple search field, but in reality are a button that opens a dialog with promotions and once you start typing it works like a suggestion combo box. Three UI elements looking like one different UI element.

The cost of fixing (accessibility) bugs

In 2002, the U.S. Department of Commerce’s National Institute of Standards and Technology (NIST) published a report called “The Economic Impacts of Inadequate Infrastructure for Software Testing”[^ Find a PDF version of the report linked on the NIST website (probably not an “accessible” PDF).]. This NIST report looked into where testing would be most efficient to find and correct bugs during a software life cycle.

The findings and methodology of the report are interesting, and I would recommend taking a look at it. Table 5-1 is very illustrative of the problems of correcting errors late in development:

Accessibility audits almost always happen after launch, as an afterthought. That means that errors that could have been found in the requirement analysis are 30 times harder to fix[^ Note that this is a “counterfactual” or hypothetical example. The report goes into detail to show that different companies in different circumstances have different factors here. The main point is that fixing any bug post-launch will be more costly than avoiding or fixing it beforehand.]. This makes accessibility audits seem very inefficient.

To address this, accessibility people recommend shifting testing to the left. Every accessibility issue that is discovered early pays off many, many times. Even more so if you avoid the issue outright. This is what table 5-2 from the report demonstrates:

Now, of course, some teams are quicker remediating issues later in the life cycle, but other teams are not. Every team has to find that balance for themselves. My observation is that most teams go from “let’s fix the errors in this report” to “this is tedious, how can we avoid making mistakes in the first place?” really quickly.

Avoiding accessibility bugs in the first place

One of the frequent questions clients ask me is: “How would you address this issue?” In many instances, my response is that I would not have created this UI component/interaction/design in such an inaccessible way in the first place.

With the knowledge of the guidelines of accessibility in mind, a lot of the issues can be avoided by the decision to implement simpler, easier to code and test designs. That does not mean making designs and interactions less appealing, but taking the route of least resistance.

Some examples:

• Before the <dialog> element was widely available, instead of using custom-made and therefore complex and error-prone dialogs, I often opted for simpler solutions, like expandable sections on the page.
• Instead of hand-coding a custom select box for styling, I would be content with changing the appearance of a native one.
• Instead of dynamic error messages for forms, I’d let people submit the form and design the error messaging really well – with an overview list, the number of errors in the title, and links to the specific erroneous fields.

I understand that not everyone is in the position to make these decisions, to trade fidelity for speed. But it feels that in a glossy Figma-driven world, many are not aware of easier options.

It’s essential that web designers and developers learn how to create simple, straight-forward experiences that are not always fancy. The goal is not to make websites boring – a common misconception about accessible websites – but allow time to do the important, complicated interactions right.

Audit reports are often long and complicated

One of the most challenging tasks as an auditor is to communicate errors and fixes efficiently. I have made reviews that fit on a couple of pages and also in-depth audits of many web pages that spanned hundreds of report pages.

The reality is that the usefulness of an audit report is getting worse and worse after maybe the first dozen tested pages. What’s wrong there is wrong everywhere. These days, I test fewer and fewer pages if I can help it. This keeps audit reports shortish and also allows for easier remediation by clients.

I generally include:

• Essential and typical workflows: This could be “buying a thing in the shop and checking out” or “creating an account and interacting in a chat interface”, for example.
• Important pages: Pages where people land on from external sources, including the home page, legal information, accessibility information, contact forms.

I make clear that all issues are only examples and that I trust that the developers know their code best and find other instances. I usually also include consulting hours to work through open questions over time.

Keeping error descriptions brief and clear is also important. Most clients are uninterested in why something is broken, their goal is to fix it. Nevertheless, this is a great place to add some education into a report. Refer to the interactions of disabled people that are disturbed by the error and why it is important in one sentence or two.

Then give the most comprehensive solution that you can. It’s OK if that is “Change this implementation to follow this blog post[^ Who are we kidding, it’s 99% a link to Adrian Roselli’s excellent blog!]”. Or just a snippet of code. Make fixing errors not intimidating.

Remember that most designers and developers getting these reports are new to accessibility. That’s also the reason you have to explain the same concepts over and over again. Most web developers were not even in their teens when you taught alternative text in 1999.

Of course, these indirections lead to a heightened effort for accessibility: Auditors have to get access, understand the site, structure and conduct their testing, putting the results in an easy-to-understand document, and hand it over to explain to designers and engineers. And those people then have to translate it back for their needs.

Why not fix it for them?

Remediation as a service can certainly work in projects where no development team exists that regularly deploys updates. Smaller online shops come to mind. Sometimes embedding accessibility into larger organizations also helps to quicker translate the needs to fix accessibility internally.

But for the small project, a theme update or a new plugin can make the site inaccessible again. With larger projects, the risk is that people rely on the accessibility person’s expertise and not enough knowledge transfer happens to make accessibility stick.

In addition, the people working on the code already know it best. If they are not burdened by processes, they can often make fixes remarkably quick themselves.

There is no one-size-fits-all situation here. The approach that seems to work best for the teams I work with is a good review with details and then regular consulting check-ins to help them along the way. I have seen many teams getting self-sufficient really fast, learning along the way.

What you can do to expedite audits

Attempt to fix the basic accessibility issues. While automation will not fix all your accessibility issues[^ and neither will “AI”], a good number of technical errors fall into very easily detectable categories. Getting these top issues fixed will make a real difference to people. Think about hiring an accessibility person for a few hours to talk you through the results of your automated testing and suggest fixes. This can also help to guide you to the right path when your ideas are wrong or overly complicated.

Going through this process also helps to define what an audit might entail and makes good sample decisions easier.

It’s also important to not be minimalist when fixing issues. Don’t discuss what the minimum is that you need to do to just pass WCAG. When we recommend a best practice solution, implement it along the guidance. It’s easy to split hairs whether a Success Criterion is really failed or not, but that energy is often spent better elsewhere. The same goes for auditors as well. Try not to be overly pedantic, and be patient and compassionate when reporting issues. It helps nobody to be antagonistic. Resolving high-impact issues is more valuable than the long tail of little technical infractions.

Because, of course, this SC has multiple sections:

Rewriting this Success Criterion for UI components only could look like this:

Visual information required to identify user interface components and states must have a contrast ratio of at least 3:1 against adjacent color(s), except for inactive components or where the appearance of the component is determined by the user agent and not modified by the author.

A practical example

Oliver Schöndorfer, who runs Pimp My Type and its associated YouTube channel, posted the following image to LinkedIn recently, accompanied by the question:

Does this pass WCAG 2.2 color contrast, dear #A11Y and UI design folks? I’m relating to Success Criterion 1.4.11.

The question is (in my words): If a UI component has a border and the contrast is at least 3:1 against only one side of the border, does the UI element still meet WCAG SC 1.4.11 Non-Text Contrast?

To be able to demonstrate how to apply the success criterion, I have recreated the form in HTML and CSS (Codepen):

I tried to stay true to the original without being pixel perfect. I also had to guesstimate the colors from the compressed social media JPG. In the end, I decided to use the following colors:

• Border color: #9b929b
• Input background: #ffffff aka white, a contrast of 3:1 against the border
• Dialog background: #f8f3e2, which has a contrast of 2.7:1 against the border

With this groundwork done, we can dive into seeing if the form fields meet the minimum contrast requirements of WCAG. Notice how we don’t even look at the question Oliver posed for quite some time, as we first need to look into the possibility that this Success Criterion doesn’t even apply:

Does it meet exceptions?

The first step of seeing if a Success Criterion even needs to be looked at is to check exceptions. If the UI component (in this case) is covered by an exception, it’s an automatic pass, and we don’t need to think about it further. Let’s remind ourselves what the exceptions are in this case:

…, except for inactive components or where the appearance of the component is determined by the user agent and not modified by the author.

Inactive component?

The graphic does not provide us any information about the interactivity of the input fields. It’s unclear if they are “inactive”, but I think for the question to make most sense, we can assume that this is an active login form. This exception does not apply.

As a reminder: Inactive components in HTML are inputs that have the disabled attribute or are made to work like a native component that has it – no mouse or keyboard or other interaction, and no inclusion in the accessibility tree.

User agent component?

This exception is very narrow, and its goal is to cover UI components where developers have no influence over the rendering (let’s say a native file or color picker). Sometimes developers can also take standard components to prototype, or for quick development of unexpected functionality. However, once you modify the UI element in any way, you’re on the hook for the proper color contrast, this includes changing the color of the text.

In our case, this exception also does not apply, as the input forms are designed (colors, borders, rounded corners).

What visual information is required?

That leaves us with the rest of the requirement:

Visual information required to identify user interface components and states must have a contrast ratio of at least 3:1 against adjacent color(s), …

The question that we have to ask ourselves is: Is the border visual information required in the context it is in? In most ordinary forms, I would say that this is the case. Where to click and see where form fields are is essential to filling out the form. Forms are usually not universally designed: Sometimes an associated field is below its label, sometimes next to it, and occasionally the form field is above the label.

But this is a very specific form: A login form. And it is in a dialog. As Patrick H. Lauke wrote in a LinkedIn comment (slightly edited for clarity):

Even if there was no contrast between the border and the inner and outer colour, it would arguably pass because the placeholder text there gives a hint that there’s an input field. So there’s no hard need for the border to identify/perceive the presence of the field.

To demonstrate this, I’ve removed all color from the login form:

Without the border, the placeholders together with the labels and the positioning act as the visual information to identify the form fields. The border isn’t even needed, so we would determine that this passes the Success Criterion. This is why the context is critical, and also why it is so tough to automate accessibility.

Just to be clear: Passing WCAG does not mean that it is a good design. It just means that you did meet the lowest bar.

Removing the placeholder text

In accessibility, we generally argue against placeholder texts, as demonstrated by this placeholder text research by the Low Vision Accessibility Taskforce of W3C. And while placeholders have the most impact when they are replacing labels, in this instance they are completely redundant to the email and password labels.

If we remove the placeholder, it becomes much less clear where to click. Yes, the most likely position of the form fields is underneath the labels, but that would be a pure guess, and guesswork like this means that the visual information required to identify the UI component is missing.

So this is when Oliver’s question becomes relevant! We’ve identified that the borders are indeed the “visual information required to identify” the UI component if there are no placeholders. With colors and borders added back in, it looks like this:

Next step! The requirement says that the UI component must have a contrast ratio of at least 3:1 against adjacent color(s).

One misunderstanding that I have seen in the LinkedIn comment underneath Oliver’s post was the assertion that the border must have a minimum 3:1 contrast ratio against both, the background of the input field and the background of the dialog. If that was the case, this would fail because we (deliberately) picked one color that is less than 3:1.

But this is not what WCAG requires (as the bare minimum) here. The border is not the UI component, the input field is, so this is about colors adjacent to the input field. Because WCAG is written in a way that works for all technologies, it does not care about where the CSS for the border is actually applied to:

An <input> element with a border would be judged the same as a border-less <input> element with a <span> around it, where the border CSS is applied to the <span>. It’s always about how the complete control is perceived by a user.

To be conforming, we look for a 3:1 contrast edge. That edge is there between the background of the input field and the border.

The easiest way to verify that it’s a sufficient edge is to “level out” non-conforming colors. The dialog background color and the border color could be the same color (with a contrast of 3:1 to the input field background) as far as we’re concerned, it would not change how we determine conformance. Colors with less than the minimum contrast are always insufficient, no matter if that contrast is 1:1 (same colors) or 2.99:1 (different colors).

So with the dialog background color being the same as the border color, we get this outcome:

Because the input fields are easy to recognize here, we can be sure that they conform to WCAG. (Yes, in this demonstration, the contrast of the text does not meet the contrast ratio, but this is irrelevant for finding out the impact of the border.)

Why does it say adjacent color(s)?

Depending on your use case, you might have several adjacent colors instead of one. Imagine the input fields had a background gradient for some reason. Some adjacent colors would be insufficient. This can make the determination if a user interface component meets WCAG much more complicated. (And you thought this was already a long article!)

In that case, you would mostly do the same as above but for every color change: If the color change is insufficient, you disregard it and “level it out”. Then you look at the resulting shape: Would it be possible to recognize the user interface element? Then it passes.

Is this good design?

WCAG does not define what good design is. Its goal is to have Principles and Guidelines that guide you towards an accessible result. The Success Criteria are guardrails that make sure you’re not completely on the wrong track. (See: WCAG 2: Guidelines and Guardrails)

In most cases, doing the bare minimum is not making it particularly easy for your users to interact with your content. It only ensures that people with disabilities are not entirely shut out. I would recommend always using a more contrasting color for the border, and also suggest using a 2 pixel wide border:

Some additional considerations

If you can, optimize the design before implementation. That includes the positioning of the links for creating an account and requesting a new password. In the design above, they are underneath the “Continue” button, which means some users that navigate through the page linearly with the keyboard or screen readers don’t encounter them until after the form has already effectively ended with the “Continue” button.

To make these links easy to discover, I put a link next to the login heading that says, “or register”. The “Forgot password?” link is put directly after the password field. In addition, I reinstated the underlines on the links and used CSS text-underline-offset to allow for a little more breathing room between the link text and the underline.

Avoid putting form related information after the submit button of a form, common instances where this happens are coupon code fields or terms and condition checkboxes. All information to complete a form must be available before submitting it.

And because the current technology en vogue is “AI”, currently some people float “AI” as the way to make accessibility happen, and not just “improve some aspects” or “help some users to get to better information”, but in the sense of “nobody will need to know anything about accessibility, as AI will make it irrelevant”.

This is a dangerous proposal. In her book Against Technoableism, Ashley Shew outlines how accessibility “solutions” are often forced onto disabled people by nondisabled people who do not share the experience and think that they know better.[^ Disclaimer: While I have a history of being disabled (child-age asthma), I would not consider me currently disabled as it was only a temporary disability.]

A few weeks ago, Jacob Nielsen formulated the following idea in his ill-advised column:

I foresee a much more radical approach to generative UI to emerge shortly — maybe in 5 years or so. In this second-generation generative UI, the user interface is generated afresh every time the user accesses the app. Most important, this means that different users will get drastically different designs. [… F]reshly generated UIs also mean that the experience will adapt to the user as he or she learns more about the system. For example, a more simplified experience can be shown to beginners, and advanced features surfaced for expert users.

And now Gregg Vanderheiden writes along the same lines on the Accessibility Guidelines Working Group[^ The Accessibility Guidelines Working Group (AG WG) is the place that develops all W3C Accessibility Guidelines that are not ARIA related. It’s the successor/renaming of the original Web Content Accessibility Guidelines Working Group or short WCAG WG.] mailing list, the group he formerly chaired:

You [Patrick H. Lauke] asked — when does it end?

wow — I hope it ends with us not having to do anything (or almost nothing) with regard to accessibility regulations for ICT because each individual gets information and interface presented to them that is optimized for them as an individual !

This is a dangerous and impractical idea for many reasons, including:

• Consistent user interfaces are easy to use and remember. User interfaces that change shape or hierarchy when the user interacts with them will make them harder to use.
• User Interfaces are designed with intention[^ at least they should be], they are to guide users to a specific outcome. An “AI” cannot know a certain intention, it might come up with interfaces that are harder to use.
• How dynamic would those adaptions be? Would a website look different when I get there with a migraine? And if so, will the generated UI that I need to learn be better for me, or would I be done with my task before I had even learned the UI?
• What would be the parameters to adapt the UI? Where would the “AI” get the information about the website? Directly from the database? From a general purpose UI?
• How would an “AI” make sure that a website is inclusive? How would it prevent to leave screen reader users with a text-only version, excluding screen reader users with sight from imagery?
• How would the “AI” know what the user needs? Does this put an unnecessary burden on the user to communicate needs in detail and accurately to get a usable result? Is that not shifting the burden for accessibility from paid professionals to disabled people?
• What about cognitive disabilities? How does an “AI” ensure they do not continue infantilizing people with cognitive disabilities and keeping vital information from them? This already happens today because humans make assumptions about others. That’s why I think it’s essential that the original, unchanged content is always available to everyone.
• Also, I do not see a world where companies are willing to give one of their main marketing avenues in the hand of “AIs”.

Hidde wrote in detail about the “generateability” of UI.

Now, Gregg might be thinking about user-side “AI” to make those changes. And I think enhancing user preferences, especially in mainstream browsers, makes a lot of sense. I even helped to start a W3C Community Group about that a few years ago[^ That was before I realized how bad my burnout from W3C work was, so I had to stop.].

But none of that is “Generative UI”. It is a base UI, which must still be accessible and then adapting it to user’s needs. And yeah, currently, we need to write custom CSS to do this, or go through browser and operating system settings to select the options we need.

This can surely be automated: “I want my websites to display text at least 12px and fill the available viewport. Display them in an off-black background color with pinkish-white text color.” Taking an LLM and interpreting that into a custom style sheet or operating system settings makes a lot of sense to me to lower the barrier of entry for these settings.

The simple fact is that we already have all the technology to make wide-spread accessibility a reality. Today. We have guidelines that, while not covering 100% of the disability spectrum, cover a lot of the user needs. User needs that fundamentally do not change.

Will we have some “AI” technology breakthrough at some point? Maybe. But do we really want to squander “AI” technology on simple things that are essentials? Like having “AI” figure out the text on a button or the alternative text of the 1000th edit pencil icon? Is that a good use of our resources? Especially with the incredible amount of energy these models currently use.

I wished I were surprised that people who used to be leaders during the web revolution cling now to the next thing[^ I’m especially not surprised that Vanderheiden is an AI fan, he planned to sit on a panel with Overlay vendors until the panel got cancelled because contrary to claims in the conference’s program, it was not IAAP sanctioned.]. It’s challenging to stay relevant. But there isn’t even experimental evidence that the “generative UI” works, let alone that it will be production ready any time soon. “Generative UI” is nice speculative fiction, but it is that. A guess of the future.

Tech “leaders” promised self-driving cars “next year” for a long time. Disabled people are often used in their marketing. Finally freeing them from the need to stay at home. But the reality is that better infrastructure, mostly through public transport and safe to use pedestrianized areas (with car access for those who need it) already would solve for a lot of the need. Would self-driving cars still be an improvement or even essential for some? Sure. But they do not (meaningfully for everyone) exist.

So let’s improve what we have, and make the world and the web better now, instead of waiting for lofty technologies that may never come.

This is not news for anyone who is disabled, of course, and it shouldn’t be for anyone who works in the field of accessibility.

In fact, cultural ableism is often the greatest obstacle to overcome – for some disabled people, quite literally. Ableism during an accessibility project can manifest in different ways, the most common are probably:

• Limited budget because accessibility is not considered that important.
• Undereducated project managers, designers, and developers because other topics are always more critical to get trained on.
• Endless discussions on what and how to implement accessibility because investing time into discussions seems more important than just doing the thing.

I think most people involved in accessibility are doing it in good faith. I think they want to change and improve and make their product better. But they are held back either by the climate of ableism or by their own internalized bias.

That’s, of course, not an excuse, but if we intend to dismantle ableism, we need to acknowledge it and its mechanism.

Accessibility doesn’t just happen in an ableist world

Often, when starting projects, clients have the expectation that they have done a good job with accessibility. But when you ask them about their quality assurance process or how they have ensured that their code is accessible, they regularly draw a blank.

The expectation is that accessibility comes automatically with a certain framework, or that smart programmers and designers will naturally come up with accessible solutions.

Sometimes, the answer is “we agreed to produce accessible code” and then you find misguided techniques in the code because the developers were asked to just learn on the job.

But accessibility doesn’t just happen in an ableist world. The mechanisms and automatisms are not tuned to produce accessible content, code, or designs. As a designer, developer, project manager, and really in any role, you have to focus on accessibility and do it intentionally. Every day of the week. Because it will not happen automatically.

You must be anti-ableist.

I see ableism in line with racism and fascism in that there is no neutral position on these topics. If you are neutral on racism, you will live in a racist society. If you are neutral on fascism, you will live in a fascist society. Only if you are anti-ableist, investigating your biases and practices, as well as seeing ableism in the world around you, you can succeed. Otherwise, the inertia of an ableist world will make your work ableist and therefor inaccessible.

As accessibility people, we often look at the end product and say “this is not accessible” (often meaning “this does not meet the minimum standards set out by WCAG”). And yes, it is always difficult to make everything 100% correct. Nobody’s perfect, and we have to make sure that perfect is not standing in the way of progress.[^ Hi Meryl.]

People love to claim that “accessibility failed”[^ No, I won't link to the Jakob Nielsen piece, but instead leave this Mastodon post/thread by Adrian Roselli which lists all the rebuttals.] but Léonie Watson describes plenty of interactions that would not have been possible a couple of decades ago. These advantages did not all arrive at once. It’s step by step improving accessibility.

The same goes for making the physical world more accessible: Curb cuts are essential for people using mobility devices, be that wheelchairs or walkers, to get around efficiently. Of course, you might say, we should have started with curb cuts earlier, and we should have accelerated the implementation of curb cuts. And I agree in principle. But there are always other constraints, in this case (and many others), it’s all about the money. Still, there is no denying that cities are more accessible due to the curb cuts.

For accessibility, we like to look to the WebAIM Million survey report. It says, “96.3% of home pages had detected WCAG 2 failures!” This sounds like a lot, but it is also like asking, “How many cities have all their curbs cut?” I’m pretty sure that percentage is lower than that of accessible home pages.

This is where the binary pass/fail of WCAG as a whole can’t convey the nuance that is needed in the conversation. Let’s look at the top 6 issues and see if we can see a positive or negative trend (change in percentage points):

• Low contrast text
  • 2019: 85.3%
  • 2023: 83.6%
  • Change: –1.7%
• Missing alternative text
  • 2019: 68%
  • 2023: 58.2%
  • Change: –9.8%
• Empty links
  • 2019: 58.1%
  • 2023: 50.1%
  • Change: –8%
• Missing form input labels
  • 2019: 52.8%
  • 2023: 45.9%
  • Change: –6.9%
• Empty buttons
  • 2019: 25%
  • 2023: 27.5%
  • Change: +2.5%
• Missing document language
  • 2019: 33.1%
  • 2023: 18.6%
  • Change: -14.5%

These are genuinely great numbers in terms of progress, especially as these issues make it impossible for some to not use affected websites at all. And even then, this says nothing about the severity of the issues because where they can have a major impact on the accessibility of a page: If links in the main navigation are empty, the impact is much higher than when social media links in the footer are empty.

Sweeping statements that accessibility “has failed” are often misguided. Improving 10 percentage points of accessibility errors in a category in four years is good. It’s trending in the right direction. Of course, there are still a lot of issues, but that is to be expected. I’m excited to see the details of the 2025 survey. (But really, developers, we have to talk about empty links and buttons, you can do better!)

That is also only the technical side of things: There are laws, like the European Accessibility Act, that are coming in effect which hopefully accelerate the adoption of good practices. I work with several high-profile clients, and there is a lot of work happening behind the scenes to make the deadline. Try a website or online shop that was inaccessible to you a year ago, it might have improved in the meantime.

And some of the machine learning also improves steadily. That podcasts now come with transcripts by default when using Apple Podcasts is a great change (even if they won’t be perfect in many circumstances). But I think even more important is that podcasters who can provide their own, better, transcripts, now have a documented way to do so that could show up in other podcatchers as well.

It’s not all doom and gloom as it might seem (although it is always totally OK to feel that way) and we have to acknowledge the progress we make every day.

Of course, I knew that getting there would be a struggle. Too many people don’t care about disabled people until they experience disability themselves. But I hoped it would get easier over time. Technology advances, browsers got better, we front-end devs got many more tools to make websites beautiful and accessible.

I joined W3C/WAI in 2013 because I imagined I could change the world there. A little. Your work has a much better impact when you conduct it at such a pivotal place in our community. For the first few years I had a blast and contributed to wonderful projects, like the Web Accessibility Tutorials, the WCAG Quick Reference update for WCAG 2.1, and the redesign of the WAI website. Despite the frustration around the bureaucracy, the impact was worth it. The accessibility tutorials alone got many millions of hits during the years, and I still get appreciation for the Quickref when I mention my involvement in it. That said, I never felt that I had done enough.

The WebAIM million in aggregate only shows an improvement of 1.5% of home pages where no WCAG error can be automatically found between 2019 and 2023. While that sounds like almost no progress, 15,000 home pages have been fixed over that time. That’s not shabby at all!

And if you go even deeper into the data, there is even more hope to be found. Missing alternative texts: down 9.8%. Empty links: down 8%. Missing form input labels: down 6.9%. Missing document language: down 14.5%.[^ These are absolute percent differences.]

This is great progress. The WebAIM million shows us that it is difficult to make websites 100% compliant, but it also shows us that progress is made. We have to see that progress for what it is – good trends in the right directions.

I have seen the main WebAIM million number (“96.3% of home pages had detected WCAG 2 failures!”[^ That’s literally the quote from the WebAIM website, including the exclamation mark.]) quoted in relation to the need of overlays to make accessibility work.

For those who are not aware, accessibility person Mike Paciello has joined AudioEye, a company that is, among other things, known for using SLAPP suits to silence critical professionals. And where we had a fairly unified front against overlay technologies, some accessibility leaders started to schmooze up to them: “Maybe Mike can turn the ship around!” – “This is perhaps a sign of them changing!”

I don’t see this happening. There hasn’t been a public apology for the deceptive marketing, there has been no moves that inspire trust that this happens. Fool me once, shame on me. Sue acclaimed professionals, shame on you.

But it shows that the old marketing trick, to find a popular testimonial in the community you want to market to, works.

The fact is: Apart for determining if a website meets WCAG 2.2 AA, for example, meeting WCAG 2.2 AA is not that important. Removing the barriers that prevent people from using a site is much more critical. Some bad color contrast in the footer? Almost irrelevant. Social media icons without alternative text? Annoying but hardly preventing users from reading the actual site.

Seeing people aligning themselves with a person they trust and have trusted over the years is understandable. So is having the hope that they can turn the ship around. I understand that.

I understand that because I imagined being able to have a bigger impact at WAI. I hoped that we could be more agile, provide developers with better, more frequently updated information. I hoped to have an impact that made it more effective. And while I think I did a little, at the end that hope burned me out. Expecting a single person to fix an organization or company will eventually lead to disappointment.

The truth is that I’m still burned out from this experience. And I think it’s common among accessibility professionals. We believe in a better world, we believe in a world that is accessible by default. Most of us believe in a world where we don’t need automatic tools that fix issues that could have been easily prevented in the first place. And most of us believe that real accessibility is also much more than just fixing programming errors.

I still have hope in the community, in the honest community, that wants to make the world a better place. In those who think teaching people how to make better decisions when creating websites is more important than giving them an half-assed way to paint over the cracks.

But I have lost hope in so many people I’ve considered accessibility leaders over the years. It used to be that my biggest criticism was that they were too timid to actually tackle the issues at hand. And I think that this contributed to the situation we are in now. Where even people who should know better try to find the magic wand that solves accessibility.

To be honest, I struggle with where to go from here. With more money, the industry has become incredibly toxic, far from the collaborative environment I experienced 15 years ago. If there is a quick buck to be made, it is made, often to the disadvantage of disabled people. I’m sad that this is happening because I had hoped that we would be better than that. Maybe we can turn it around.

(See the previous post for some context on yearly themes.)

The Year of Intent in 2022 worked out very well. I felt better and more intentional. Unfortunately, it lost all its power over 2023. Extending the theme this way was unintentional, which basically set the whole year up for failure from a yearly theme/north star perspective. I never really caught up with anything over 2023 and always felt behind.

The Year of Focus on Focus continues a little from what I have subconsciously done in 2023: I drastically reduced my commitments and took breaks instead. Saying “no” to some things gave me space for saying “yes” to other things. And I want to continue that.

But Focus on Focus is also a promise to make changes that benefit being focused. I felt spread thin, stressed, and tired at the end of 2023, and the break hasn’t really helped, unfortunately. Focusing on the focus is the attempt to get the rhythm back, to create the space to be sustainably productive. I hope that that works out.

Of course, it is common knowledge that automated tools for finding accessibility issues can only find a limited number of issues (probably about 30–50%). Fixing issues needs additional context and care. I assume that is one of the reasons why the overlay providers themselves have started to add manual audits and remediation to their portfolio, including UserWay.

This is not a distraction for Level Access CEO Timothy Springer, who writes in a long piece on LinkedIn the following paragraphs:

The chief criticism of accessibility overlays relates to marketing claims.

This is not true. If you look at the Overlay Fact Sheet, none of the outlined problems have to do with the marketing. These are all criticisms based on the merits of these “solutions”:

1. Overlay widgets are unnecessary and are poorly placed in the technology stack.
2. While some automated repair is possible, customers should be discouraged from using an overlay as a long-term solution.
3. While the use of an overlay may improve compliance with a handful of provisions in major accessibility standards, full compliance cannot be achieved with an overlay.
4. Adding an overlay to your site may run counter to end users' preference for privacy and may create risk of noncompliance with GDPR, UK GDPR, CCPA, et al.

Yes, the advertisements are problematic, including UserWay claiming which says:

Our Widget has quickly become the world's leading accessibility plugin and compliance solution, now installed on millions of websites worldwide.

The leading compliance solution is to comply with accessibility law, not installing a widget. The easiest way to integrate accessibility into projects is by thinking about it from the beginning.

(According to UserWay’s 2023 financial report, they also have 6800 paying customers, I guess there are millions of websites out there using it for free?)

Back to Timothy Springers post:

The technology of overlays works. Truth is it actually works very well and does so at scale. In that, it can positively impact the accessibility of millions of sites. The marketing claims, the effective use of that technology as part of an accessibility journey, are what needs work.

It does not.

I linked to the technology criticism above. This is technology that cannot work well enough to cross the threshold from uncanny valley accessibility to real accessibility. Because in the end, this is about humans and how they interact with the web.

The reality, as I see it, is that overlays do very limited things ok, but also miss things that would take less than a minute for a developer to fix.

I recorded a 50-minute walkthrough of the Beyond Meat website, which is advertised on UserWay’s website, using the overlay. In the end, my conclusion was that the website is not substantially better with the overlay compared to without the overlay.

Indeed, when I tried to stop the animation using the overlay (the website does not respect my “do not autoplay preference”), the overlay made the animation flicker rapidly. It was worse than without the overlay.[^ Update January 28, 2024: This behavior seems to have stopped at some point during the last month. I guess a fix was implemented (which is good), but I have not seen any communication about this.]

Setting the anti-seizure setting while the animation was playing triggered a potentially seizure-triggering flicker effect.

Now, Timothy Springer claims that users won’t need to use the functionality in the widget anymore in the future:

Some accessibility overlays require a user to click to activate its automated remediation. For us, automated remediation must be active and always on for every user. Every user should get the same, accessible experience.

This is table stakes. But if the website only works on the client side and shares cookies with a third-party domain, a disabled user who would need automated remediation would be forced to accept that. With all the security and privacy implications that using a third-party script brings with it.

Is that an equal experience?

Even if your code runs automatically, a pause button for the animation would need to be provided. And if users use them, and it works badly, then that’s bad luck.

Or, as Timothy Springer says (emphasis his):

Automated remediation and browser-based tools should never interfere with user installed AT. If they do, we will treat this like all engineering issues and address the issue. And, browser-based assistive tools will always be optional.

“We put it in our backlog” is not a suitable way of implementing things. This puts the burden on disabled people to find and report errors and wait for remediation before they might be able to use a site efficiently.

And that is the process we have today in accessibility. But with an overlay, you are not relying on your staff or site builder to fix an issue, you put that into the hands of a third party. A party which can also introduce accessibility bugs at any time (for which the site owner might be liable).

Timothy Springer again:

What gets missed in that, though, is that there are millions of websites whose owners have neither the funds nor technical depth to develop a comprehensive digital accessibility program. Cost is the biggest barrier for these firms. Level Access can either provide a principled, compelling, cost-effective solution they can say “yes” to today, and get started on accessibility, or keep doing little for these firms. If we’re smart about it, that starting point will materially improve the accessibility of these sites today. Now.

While cost certainly plays a role, a widget which at best does little and at worst provides barriers is not “cost-effective”. Quite the opposite. I understand that a company that throws around 99 Million Dollars for an overlay company finds it difficult to do small-scale accessibility.

But that is OK.

The small website widget costs $490/year at UserWay. This can easily pay a developer to go through templates and remove accessibility blockers. Or it can help pay someone to test and recommend an accessible theme for the shop. Those are permanent fixes that will bring you much further than paying for a widget which will have no long-lasting impact.

Accessibility is not expensive, inaccessibility is. And not because you might be sued, lawsuits are still incredibly uncommon, considering how inaccessible the web is. But because you show your customers that you don’t value them if they have a disability.

Investing in permanent change might look slow in the beginning, but always pays off over the long run.

And that brings me to one of the highest impacts of overlay companies on the accessibility community: It drains the money out of smaller assignments which are essential to training up new accessibility people. Sure, as a company you won’t make a massive profit off a $1000 review, but if one of your juniors can use it as an exercise under supervision, it is a wonderful learning opportunity.

There is a lot of discussion that we need automated tools because there are so few accessibility professionals, but imagine Level Access had paid 99 Million Dollars to train their employees or subsidize companies who cannot pay for it. Would that not be a more sound investment in accessibility?

But let's not lose sight of why this is happening: Profit. It’s an already gigantic company that wants to profit from all parts of accessibility. Even from those who are getting tricked into thinking that there is an imminent risk of getting sued and sold a placebo.

Even then, even if you believe there is and should be a market for overlays, then… they already exist. There is nothing here that fundamentally changes them through this purchase in that regard. There are plenty of overlay companies that are already providing this service. Why would you want to be part of it?

The UserWay CEO will be “President of Level Access” in the future, and the UserWay company will continue to operate. It feels hard to believe that the marketing and focus of a company will change, especially if so much money has changed hands. The promises Timothy Springer makes hint to changing UserWay, which leaves the question: why buy them instead of building something better?

Equality now is better than equality later

Accessibility is not a profit business. Sure, it can pay well for people who have expertise, but ultimately, it is a craft that is limited. Yes, some tooling can make aspects easier. Definitely, you can lint and autotest the hell out of your code. But eventually, the only thing that really makes your product accessible and inclusive is thinking about the inclusive experience constantly. Not as an afterthought, not as a bolt-on, not as something extra.

Companies need to decide if they fall for the uncanny accessibility of overlays or start the learning process with a trustworthy non-overlay provider. Starting now, even with little investment, can be the start of building an accessibility understanding that will be beneficial for a long time.

This year was very different from last year. I did not bike a single kilometer, which feels super bad, and if I have one personal goal for 2024, it’s getting back on the bike again. That said, we did rent a car to find hiking trails and hiked quite a bit during the summer. So not all is lost.

I also built many more Lego sets, so many in fact that this is getting a space concern. That said, they help me to keep my nerves down.

I started reading Dan Moren’s All Souls Lost book. (It came too late for the summer holidays, and I haven’t gotten into the habit of reading over Christmas.)

TV is still one of my main hobbies, and there is so much good stuff. Not only got four Doctor Who specials released, which are all excellent. (BBC/Disney+) I did enjoy the continuations of For All Mankind, Foundation, and Slow Horses. Shrinking is extremely well-made, too (all Apple TV+). Loki Season 2 was exquisite, while Secret Invasion existed. I enjoyed watching through Star Wars Rebels and then Ahsoka (all Disney+). Good Omens continued in a surprising and fun and tragic way (Amazon Prime). So much good TV.

Formula E season 9 was spectacular, and I cannot underline enough how much fun that series is. The behind-the-scenes dramatization of the season (Aka FE’s Drive to Survive) called Formula E: Unplugged will be published on January 2, with the first race of the season on January 13.

I also fell into a Home Assistant rabbit hole. After running a Homebridge for several years, this is a huge upgrade and wow can smart home stuff be easy and powerful. Having everything in one app that can be highly customized is empowering.

This blog and beyond

Including this post and with three posts that I imported from my retiring microblog, I have published 16 blog posts. That’s not bad.

I also started to take my newsletter more serious and sent out four of them. I try to make them more personal but also look at the industry of accessibility, trying to improve it. In the last one, I wrote about my thoughts on the European Accessibility Act and how prepared we are to support all businesses who will need help.

I also created a bot in April that collects interesting links on the web regarding accessibility and then publishes them on Mastodon. You can follow @links@yatil.social or see the Raindrop.io collection. It even has an RSS feed!

What else?

The loss of community continues, I did not have one speaking engagement in 2023, which was my own decision due to the risks of travel during a pandemic. I also stopped teaching at FH Joanneum due to the requirement of teaching at least one day in-person, but also because the teaching days shifted to the autumn. There is too much work to do in autumn for that additional commitment.

Apart from that, work was great but stressful. I did a lot of strategic and coaching work. And I feel that I’m more effective doing this than doing audits. So this is something for 2024 Eric to figure out. Especially how to deliver work that meets my high expectations for myself while also not completely draining myself.

Of course, the world situations hang like a dark cloud over everything. A largely ignored health crisis, wars, right-wing extremism, the climate emergency. I hope we can finally address the issues head-on and come out on the other end. I’m not super optimistic, but I have hope.

That’s it. I wish you a great year 2024 personally, but also globally.

But that is only half of WCAG. The other half are “Guardrails” that prevent you from producing wholly inaccessible material.

Guidelines

The guidelines consist mostly of the Principles and Guidelines (oh!) of WCAG. There are four Principles that have in summary 13 Guidelines. Those are the first two numbers of the Success Criterion number (which are, spoilers, the Guardrails): 1.1.1 Non-Text Content refers to Principle 1, Guideline 1, Success Criterion 1.

As we often focus on Success Criteria, the context of the Principles and Guidelines is missed. They can guide us to good, accessible solutions already. When people say “go beyond WCAG” they typically mean “follow best practice principles & guidelines” which are also in WCAG.

Look at the excellent WCAG 2 at a Glance document by W3C/WAI, and you’ll notice that nothing limits you to making the most accessible decision at any point.

“Go beyond WCAG” is a mischaracterization of what WCAG is. What people mean is “stay away from the Guardrails in WCAG”.

Guardrails

If you think of guidelines in the real world, you probably think of the guiding lines that you see on streets and that keep traffic separated into different lanes. Generally, you follow them, but every so often, you cross them to overtake or to make a turn. That is OK. The lines are there to guide you.

On the other hand, you have guardrails that you want to stay away from. These are the absolute limits of what you can do without getting into an accident. If you are a careful driver, you should never be very near those guardrails.

That is what the Success Criteria in WCAG 2 are. They tell you where the street ends, and you crash into a barrier. That’s why it’s so important that these are specific. A text contrast is insufficient if you are below 4.5:1 contrast.

The guideline “Make it easier for users to see and hear content” has its guardrail at a minimum 4.5:1 contrast, allowing text to be scaled to at least 200%, and that content on hover and focus stays visible.

Conclusion

It’s a myth that WCAG constricts the level of accessibility. It’s quite the opposite. I sometimes think WCAG should be two standards: The guidelines that give web designers and developers information on what to look out for, and “testing rules” for verifying that the guidelines are followed.

Unfortunately, in practice, most people learn of the guideline part of WCAG only after being confronted with the guardrails part. The tragic situation is that people would crash into guardrails less if we taught them the Guidelines first.

As it is right now, we are only a tow truck that pulls the wreckage out from the guardrails and positions it just next to them. Which means that the projects keep scraping along, sparks flying, until they break down again.

It is excellent, and I strongly recommend reading it before continuing here.

The reason we often cannot be super specific has its roots in three areas:

• The web is a complex environment. Anything can be done in hundreds of different ways, depending on the underlying technologies, frameworks, and sometimes business constraints. Recommending the one straightforward HTML/CSS/sprinkle of JavaScript/server-side solution might be a specific answer, but not necessarily a good answer for the circumstances the page is in.
• Disabled people are not uniform. They have different needs depending on their disabilities but also based on their individual preferences. That’s why we, for example, argue to leave content interpretation to screen readers as much as possible instead of dictating how something is said. That also means, as Nic mentions in his article, that there are many, many combinations of tools that users use. And even if they use the same tools, the settings can be quite different.
• Technology is inaccessible, so making something accessible is more complicated than it should be. I researched combo boxes and selects for a client yesterday and saw <select>, <selectlist> and handmade ARIA combo boxes. Which of those you use, depends on your need. <select> is simple and covers many areas, <selectlist> will cover more functionality and finally allow us to style options (at the expense of not being supported in a shipping browser to date), so the complicated ARIA combo box it is. It is not something I want to recommend, but it depends on the need of the client to what solution is suitable.

Expectation management

Nic mentions that some client teams see this as bait-and-switch. We tell them there are clear, internationally agreed standards for testing accessibility, so they expect that for every issue there is a technique to meet the success criterion. Indeed, the W3C does provide a list of techniques to meet success criteria. And look at that, there are many ways to meet these criteria.

A two-sided expectation management needs to happen. First, clients need to be aware what their goals for accessibility are. Nic has a good, IMHO, bad example in his post:

We must meet WCAG 2.2. AA, and we must make sure what we build works well in NVDA with Chrome, VoiceOver with Safari on both MacOS and iOS, and TalkBack on Android

What does “works well” mean? How well? Perfectly? What are the differences that are allowed?

I love making things easy to use for everyone as well. But that often makes the goal not a line, but a zone. Nobody knows if what they are doing is enough to meet the expectations, frequently their own expectations.

Concentrate on what is important and testable, so WCAG 2.2. There will still be enough wiggle room, but it is a goal you can work towards. It’s a minimum, but you can achieve more from a strong foundation.

And then you can move on and say, “OK, now let's make a list of screen reader interactions that we are unhappy with in the following screen readers and ask our users what they expect.” This gives you a list to work through and check off. Real concrete progress instead of mushy goals.

The other expectation that needs to be managed is especially critical when interacting with developers and designers. As outlined above, nothing is set in stone and frequently there are no simple good answers that work for you. You also might not have learned any of that “accessibility stuff” and now you’re responsible. We’re here to help. Tell us what you’re struggling with, and we can make sure to better explain and be more concrete for your individual situation.

Occasionally, the best way to help developers with their accessibility problem is to talk to project managers or designers and change the process to be easier to implement.

We’re partners in making a product accessible, and when we say “it depends”, we don’t mean “it is impossible to know”, but “let’s figure out how we can fix this most efficient, together”.

What are exclusive accordions?

Accordions are a series of expand/collapse (aka disclosure) widgets. Usually they start collapsed, and you can open each section one by one. Exclusive accordions close any previously opened section automatically when a new one opens. It means only one section of the accordion can be open at once.

A new proposal now wants to make the existing <details> element into an accordion by grouping them when adding a name attribute to it. Such an element's open state would then automatically be false (hiding the content) when another element’s open state is set to true, if those two <details> have the same name attribute value.

What are the accessibility challenges with exclusive accordions?

There are some accessibility challenges with all types of accordions, but most of them are even worse when only one accordion section can be open at a time. Here are a few examples:

• Higher cognitive load as users are unable to compare information between two sections, the accordion resetting on page reload, added difficulty in scanning and getting a general overview of the information provided.
• More complicated interaction for keyboard users who need to navigate maybe multiple times through multiple expand/collapse button to extend one section, then navigate to the next section and open that, then to the next to open that. Comparing between two section of an exclusive accordion quickly takes dozens of keystrokes.
• Reduced usability for screen reader users who use heading level navigation to get an overview of all content on the page. That’s just not possible anymore as the accordion cannot be opened all at once. Heading levels can also get quite wonky in screen readers when headings are used in the expand/collapse button.
• Low-vision users and people on mobile viewports can easily lose orientation when one section opens and another section closes as the content shifts around. This is especially problematic with content of different lengths. This can also be problematic for people with vestibular disorders. (Gareth Joyce on LinkedIn, Olli Boermans on Mastodon, Christian Schaefer on Mastodon)
• Dragon users can have a hard time opening <details> elements, as the software deprioritizes them compared to buttons and links. (Victoria Clark on LinkedIn)

These are just the three high-level points I have observed from an accessibility standpoint and two other obvious points added after the publication of this post. Most times, users really did not like accordions. The only exception is incredibly long pages that are terribly organized. And even in those instances, the need to open at least two panels happened more often than not.

But couldn’t native exclusive accordions address some of these issues?

Technically yes. I am a big fan of making it easier to do the right thing. That should be our goal. Implementing exclusive accordions, be it through JavaScript or as a native browser feature, however, makes it easier to implement a UI principle that makes websites objectively harder to use. It allows developers to deprive users of a choice.

One name attribute and your user cannot interact with the content of the page as they like. It’s disempowering the user.

If we want native accordions in browsers, we also must make sure to have guardrails for users. Browsers are user agents, so they should counteract the negative impact of making exclusive accordions easily possible.

What are the next steps?

It feels like the decision for this native exclusive accordion has already been made. There was no proper accessibility consultation, probably a direct result of HTML features being developed outside of W3C and with no accessibility review. It’s also a cheaply implemented feature; that is easy PR, too. (It’s indeed so simple, I did build it in 2016 with five lines of JavaScript.)

What I hope for now is that browsers quickly address the usability and accessibility issues around accordions, exclusive or not:

• Allow users to deactivate the exclusive accordion behavior globally and for individual websites. We have this for auto play audio and video, we need this here as well.
• The ability to expand all and collapse all accordion sections (essentially all <details> elements) on the page.
• Make sure content inside accordions is shown in reader mode.

It’s unacceptable that we introduce native barriers in HTML and the web platform in 2023. This is unbearable. When we did this last time we got broken date and time pickers, a situation that has not been addressed for more than a decade.

The web must be holistically accessible. Every feature that is introduced must be vetted for accessibility.

2023-11-17: Update to include more bad examples of what accordions do.
2025-08-05: Update to add the dates when the feature shipped and that there are no mitigations for the feature at all.

• Title: Enough with the baby steps! Let’s make accessibility leaps.
• Outline: So much of our work is based on nudging people into the right direction. Applying a little pressure that makes a change but is not disruptive. This needs to change. This talk showcases steps that we can take that make instant notable differences for disabled people using websites and apps by using policy changes that are strong and disruptive once, instead of continuous glacially slow progress.
• Additional Information: I don’t expect this to be the most technical talk, but it might be most suitable for people who lead teams or companies; hence I selected intermediate. The talk’s goal is to shake people awake and show how gradually improving accessibility is often not the best way to spend their effort.

(Slightly edited for grammar. Imported from my micro.blog.)

Being able to inspect and look at the code in these views is essential to give good feedback to developers implementing these views.

Inspect Browser (websites only)

For casual use and availability on the go (without tethering to a Mac), Inspect Browser does the job. It works great on iOS and iPadOS and provides all web inspection needs: Logging on the console, inspecting elements, finding out accessible names, and much more.

I personally use it only to quickly get to the bottom of an HTML structure or figuring out why something is announced/shown weirdly while using VoiceOver or Voice Control. It is a separate browser, so you have to log in and/or navigate to where the issue is.

Safari on macOS (websites and web views)

For websites and web views where the small-screen inspector in Inspect Browser does not cut it, you can use Safari on macOS to connect to the iPhone/iPad. You need to set up your device once:

1. On your Mac: Switch on Developer mode in Safari by going to Preferences → Advanced and check the “Show features for web developers” checkbox.
2. On your iPhone or iPad: Go to Settings → Safari → Advanced and switch on “Web Inspector”.

When you attach your iPhone or iPad to the Mac using a Lightning or USB-C cable, open Safari and go to the Develop menu. Select the device and then the website and a inspector window opens. It has the full capabilities of the desktop Safari inspector, which is very capable.

From my experience, everything that is in a normal web view can be easily inspected, even in non-iOS-Safari apps. More custom implementation sometimes suppress the ability to inspect them. I can easily inspect web views in Mona (App Store Link), my favorite Mastodon client, but have no chance in the LinkedIn app.

Check “Connect via Network” to get rid of the need of a cable connection.

You can even use the crosshair button and select elements on the iPhone/iPad by touch.

Using Siri

Siri switches VoiceOver on where you are at the moment, if you invoke it using the command “Hey Siri, VoiceOver on”. Switching VoiceOver off works by issuing “Hey Siri, VoiceOver off”.

But this way is cumbersome, and if you, like me, switch VoiceOver on and off many, many times during a testing session, unpractical. Here are some even better shortcuts:

Accessibility Shortcut (all iPhones and iPads)

There is literally a shortcut for this. Go to Settings → Accessibility → Accessibility Shortcut and check the accessibility features you use in your testing. Now, if you press the sleep/wake button three times in quick succession, a menu pops open that allows you to switch on and off the checked accessibility features. If you only check VoiceOver, it is switched on/off directly. See the official Apple documentation about the Accessibility Shortcut.

Control Center (all iPhones and iPads)

You can put accessibility buttons into Control Center (the panel that appears when you swipe down from the top right of the screen). Go to Settings → Control Center and add accessibility features under “more controls”. I have text resize in there to be able to quickly test that in apps. But you can also add “Accessibility Shortcuts” which brings up the menu as configured above.

It’s good for lesser used features, but as the popup immediately closes after selecting VoiceOver in the triple-press sleep/wake button scenario, the menu stays active here. Navigating out of it to the app you want to test is quite cumbersome, so I tend to not use it to invoke VoiceOver.

See Apple’s documentation of Control Center customization.

Back Tap (all iPhones)

If you want a little more flexibility, the Back Tap gesture allows you to gently tap the back of your iPhone twice or three times to launch either the aforementioned Accessibility Shortcut, or a number of other functionality. You can, for example enable VoiceOver with two back taps and the Accessibility Shortcut on three taps.

To configure it, go to Settings → Accessibility → Touch → Back Tap and select Double Tap or Triple Tap. Then select the Accessibility Shortcut or the function you want to invoke from the list.

(The Back Tap section has been added after I was reminded of this functionality by Shelly’s mention in her article The iPhone 15 Pro brings tangible accessibility benefits on sixcolors.)

Action Button (iPhone 15 Pro and later)

You can also put an accessibility feature, like VoiceOver, directly on the new iPhone 15 Pro Action Button. In Settings, go to Action Button and swipe almost all the way to the right to the “Accessibility” option and chose VoiceOver. Now, whenever you invoke the Action Button (press and hold briefly), VoiceOver is quickly turned on or off. See Apple’s documentation about the Action Button.

Using a combination of these shortcuts, you can make it really easy testing with accessibility features on iOS.

Accessibility must work within the constraints of an ableist world to improve things. I hope it can help to make the world a tiny bit less unjust every day.

I have seen accessibility people say “this is a hill I’m willing to die on” and then they died on that proverbial hill.

Some clients just don’t care, and you have no power to make them care. You can make them aware, you can put procedures in place, you can point at laws. But you can’t change their attitude.

And yes, that might mean that the products of the process are… mediocre at best.

That is disappointing for the accessibility professionals involved, who did their best in the circumstances, and still fail many disabled people.

I think it’s still important to do this work:

Awareness is important, and when more people are aware that accessibility is a thing, more people will be willing to invest in it. This is a slow process, but I have seen it in real life: Companies that have an audit done for compliance and then want to get better.

And sometimes you inspire people to get into accessibility, and they might have an impact for a long time.

Is any of this optimal? No.

Do I wish I had a magic wand that made disability justice a reality and everyone care? You bet!

But I don’t, and so I need to have my practice grounded in the reality of the world as it is, as it otherwise becomes burnout inducing.

And if we cannot afford one thing, that’s people quitting accessibility because they are burned out. Because they feel that they are ineffective, and their work is worthless. I feel like that all the time.

That said, the WebAIM Million study shows that between 2019 and 2022 the average error per page has decreased, and the most common issues have also decreased. The web is slowly getting better.

I strongly believe that we must change the systems to make web accessibility easier, especially aligning what’s right with what’s easy. Currently, a lot of accessibility practices on the web are hidden or require additional knowledge. That is an ableist barrier itself.

I wrote about changing the system on my blog.

I also recorded a talk about the topic.

(Previously published on my micro.blog.)

Now, don't get me wrong, a good percentage of my work is to “well, actually” people who should know better. And I generally enjoy it – using my mansplaining powers for good.

But now and then, you get that sinking feeling that you are undoing someone’s work that they created with the best intentions, where they researched hours and hours for a problem they perceived.

And I come along and say “nah”.

“Nah”, because “it wasn't a concern in the first place”. “Nah”, because “that's not how assistive technology works”. “Nah”, because “many screen reader users can see the screen”.

The reality is, accessibility is hard, especially when thinking about it holistically. Which you have to do to not leave people behind. That complexity is inherent to the humanity that's behind accessibility. We’re doing this for people that have all sorts of disabilities, that are different from one another in many, many ways.

Even looking at screen reader users, individual preferences and settings can throw assumptions out of the window.

I have lost count on how often I have seen developers adding tabindex="0" to random text because they couldn't reach it using the tab key, and so they assumed that nobody could reach it.

Of course, screen readers have ways to read text on web pages. They would be pretty useless otherwise.

This blog post was spawned by the “State of HTML 2023” survey and its question on the focusgroup attribute, which is an Open UI proposal that I had never heard of before.

Its goals are to bring the focus behavior of <select> elements and radio groups to other elements.

To recap: When you encounter an element with focusable child elements, the usually expected behavior is that the arrow keys do the navigation among these child elements.

Tab to a native <select> and use the arrow keys to make a selection. This is genuinely useful behavior. You would not want to stop at every sub-item of a select, and differentiating between these two focuses makes sense.

What could bring problems is to generalize that behavior to random elements.

The use case is custom composite widgets, but experience shows that eager developers will use it in other circumstances. It would be a better approach to define default keyboard behaviors in ARIA and let developers opt into browsers managing focus for that specific role and its children.

<!-- THIS IS NOT REAL CODE -->
<div role="menubar" aria-interaction="default">
…
</div>

That way, browsers could verify that a role is used correctly and take measures to fix misuse. Developers would be encouraged to use correct roles for widgets and their children, if they want to reap the benefits of the default keyboard interactions.

Conclusion

The power to redefine how focus works amongst a group of UI elements brings with it a great deal of responsibility to not mess it up. For most people, including many accessibility pros, it’s a challenge to decide when to use which behavior.

Developers are bound to stumble over these techniques, like they do now with over-eager use of ARIA roles or the tabindex attribute. They might implement it without checking their assumptions.

A note on the “State of HTML 2023” survey

Generally, I think a survey like this can be useful. It would be even more useful, if it would address longstanding accessibility issues and also not itself misuse HTML elements:

Radio buttons are not supposed to be uncheckable[^ You can literally click on a radio button to mark it, and then click on it again to now have no radio button marked.], but if you insist on using that functionality, it must be keyboard accessible, too.

It's also problematic that the technologies are only referred to by name without any indication if the technology is in the HTML standard (or adjacent standards), like focus group, which is a seemingly early proposal within Open UI.

Presenting landmark elements, which are part of HTML for a decade, alongside focusgroup makes little sense to me.

A note on the focusgroup proposal

The proposal does not use great HTML practices, which does not lean trust to it. A menubar/menuitem example uses <ul>/<li> elements only to redefine their roles. Just use <div> elements!

Another issue is the use of tabindex="-1" for demoting inactive elements in a focus group. Browsers without support will make the elements with that tabindex unreachable using the tab key, potentially hide interactive elements from users, which is suboptimal.

I also don’t like that it is both, a HTML and CSS proposal. It feels like there is a lot of potential for conflict when both are applied.

That said, in the early days of ARIA I had an idea to use CSS-inspired “Cascading ARIA Sheets” which would allow developers to assign roles and properties using CSS selectors and a similar syntax. I still think it could be a nifty technology to have (that would of course bring its own challenges).

What I mean by that is that often, you are in a situation where you cannot influence the culture or moral of a company. Making inaccessibility a moral failure can mean that people go in a defending position, resulting in less progress than otherwise.

For me, accessibility is mainly a set of practices that allow practitioners to build their product in a way that does not introduce obvious barriers for users. To do that effectively, of course they need to learn about the disabled experience and how people (in my case) use the web. And hopefully that sparks interest and thinking more about disability needs as a whole.

The truth is that we live in an ableist world. Most accessibility work is done against ableist headwinds. Sometimes these are blatantly obvious (“we only want to conform to the minimum standard defined by law”), sometimes they are clear in project constraints (time and budget).

If I can change those parameters, I will, and I try whenever the opportunity arises. If I can use my WCAG report to inform developers on how to think about the interaction of disabled users with their product, I will.

But in the end, it is important that the practitioners do the actual practice of putting the right elements at the right place in HTML, and know what an accessible name is. It is one of the fundamental building blocks, because you won’t have an inclusive society if you don’t have these stepping stones in place.

There are often memes going around in the accessibility space that show “curb cuts to nowhere”. Where a curb cut does end at a place where there is no sidewalk. It nicely shows that accessibility practices on their own do not guarantee an accessible experience.

That said, the person putting in the curb cut is not responsible for making their municipal government anti-ableist. Realistically, there is no way to do that. One option is to give up and not add a curb cut to that side. Or the other is to do it, so it is ready once the sidewalk is built. And in the meantime it means a flat surface area for people to stand on, and a call button that enables blind and low-vision users to cross the street.

Is that disability justice? No, not at all. Is it inclusive design? Not by a long shot. Does it create the requisites to make both happen in the future? Yes.

Accessibility on its own can improve situations, following it cannot guarantee inclusive spaces. But without accessible building blocks, you can never reach inclusivity.

(Apparently this blog post was written because I saw this LinkedIn post by Tori Clark appear – and then vanish – this morning. I tried to re-find it, but once LinkedIn has changed your timeline, it’s almost impossible.)

While WCAG 2 (and 2.1, and 2.2) has its flaws, like every standard has, it is a very successful standard. The whole accessibility industry has rallied around it, it is referenced by the International Association of Accessibility Professionals (IAAP)[^ Quick acknowledgement that both, W3C and IAAP, are allowing memberships of companies selling dubious accessibility overlays.] in their certification programs.

In addition, we have fifteen years of experience with WCAG 2 now. Tooling, practices, expectations have been set. We have found guidance and documentation that is misleading or insufficient and corrected it over the years.[^ Huge shoutout to everyone who has contributed to issues and pull requests!] We learned to explain the requirements and the ins and outs of how to address different failures.

And I think the knowledge of seeing a pattern in a code and knowing how to best meet or exceed WCAG is really what an accessibility professional can bring into a team. Identifying that something passes or fails is relatively simple, taking clients by the hand and guiding them to conformance is much harder[^ Of course, conformance should never be the end goal. But IMHO, it is a necessary stepping stone towards an inclusive product.]. And experience helps a lot in this regard.

W3C/WAI also announced a new Working Draft of WCAG 3, the next generation standard. Confusingly enough, apart from the abbreviation, WCAG 3 will have nothing in common with WCAG 2. Not even its name which is planned to become W3C Accessibility Guidelines 3[^ And yes, I am unreasonably bothered by WCAG 2, 2.1, and 2.2 having /TR/wcag2, /TR/wcag21, and /TR/wcag22 URL slugs respectively, and this one has /TR/wcag-3.0.]. This draft highlights the highly experimental nature of this specification right now.

I have written about the WCAG 3 not being ready in 2021 and this is the first update since then. I would suspect that it will take at least until the end of the decade to see WCAG 3 come to fruition, if that fast. The W3C/WAI has a good overview of the changes that might be coming in WCAG 3.

Do we need a revolution?

“[T]his is another positive step toward a much needed revolution of WCAG.” writes Léonie Watson in LinkedIn.

I don’t fully agree. Producing a new standard seems to be a solution to some of the issues that WCAG has, mainly the intermixing of guidance and conformance, hard to read language or limits of where WCAG 2 applies due to new technologies.

That said, the base principles of accessibility (perceivable, operable, understandable, and robust) will not change. WCAG 2 compliant sites won’t be inaccessible once the standard is published. Indeed, W3C/WAI says that WCAG 2 will exist long after WCAG 3 is published: “WCAG 3 will not supersede WCAG 2, and WCAG 2 will not be deprecated, for at least several years after WCAG 3 is finalized.”

Let’s say WCAG 3 is finalized in 2029[^ See, I can be optimistic!] and the transition period is five years until 2035, then this gives companies a decision point for quite a long time: Can I change to WCAG 3 while WCAG 2 is legally required? Do I have to conform to both to be future-proof?

Testers and auditors on the other side must cater for two different types of tests every time they start an audit. Sometimes they might need to use ruleset A and other times B and sometimes a combined AB ruleset. And if that wasn’t making it complicated enough, one of the goal of WCAG 3 is to move away from the binary pass/fail criteria of WCAG 2 to a graded, well, grade.

While this sounds useful in practice, there is a lot of bookkeeping involved. Currently, if an image has no alternative text (and should have one), that page fails SC 1.1.1 Non-Text Content. In the future, the amount of images might have an impact on the conformance. Test Scopes describes the current thinking of the group (the section is marked as “developing”). I think this kind of scoring will work great for large companies with in-house testers and processes, but it will make it much harder for individuals or small consultants. This part of the standard could probably be its own separate testing standard.

And indeed with WCAG 2, we have Evaluation Methodology (WCAG-EM) that does some of this.

Evolution

WCAG 2 has shown over 15 years that it can be shaped into a better standard with incremental updates. It feels wasteful that we are training people and companies on WCAG 2.2 in the next five years, only to then pivot to the shiny new thing. Which in practice will not be a significant improvement for disabled people, apart from the new cognitive requirements that, by definition, cannot fall into the pass/fail scheme of WCAG 2[^ Again, the principles for accessibility stay the same, and I’m convinced that if there are gaps, those can be filled in WCAG 2, too – if the Working Group would choose to do it.].

That said, why could the conformance model of WCAG 2 not be adapted to these requirements? Could WCAG 2 reference another standard that has more of these “squishy” requirements? I think it is totally in the realm of a standard like WCAG to say “here are the practices for readable text” and then leave it to the reviewer to make the argument for pass/fail.

CSS is the other successful standard at W3C/WAI. It works because it is an iterative improvement. Like WCAG 2, it is only additive. Unlike WCAG 2, it is developed in modules. Have a good idea for a CSS module? Spec it, have it implemented, and voilà, it’s part of CSS. This should be the way WCAG 2 works, too. If there is a new color contrast approach, why not put that into its own module, mature it on its own and when that has happened, add it to the next version of WCAG 2.

W3C wanted to reinvent an important standard, HTML, in the early 2000s. XHTML, an XML version of HTML, was supposed to be the next version. It broke compatibility with many previous HTML implementations and practices. And, in the end, it failed. W3C lost HTML to the What Working Group. If WCAG 2 is still used by laws and policies but W3C/WAI does not want to further develop it, there might be a gap for people who want to continue with the tried ways of WCAG 2.

On the other hand, how good is a WCAG 3 that only gets updated like WCAG 2, every 5 to 10 years? In any case, the rate of updates needs to increase. WCAG 2 has hundreds of open issues and pull requests, mostly for supplemental guidance like the Understanding and the Techniques. And exactly those types of information is what WCAG 3 is thinking about to update frequently. The question is: Will this be done? Understanding, Techniques and other documents are already supposed to be up-to-date. But even the correction for minor typos are often not published.[^ Like my evergreen “refow” typo in the quick reference.]

Conclusion

I know that the people who are working on WCAG 3 have the right intentions. It just doesn’t fill me with confidence to see so many issues and pull requests open for a standard and its supporting documents. As far as I can see, WCAG 2 will be on life support at best in the coming years.

I would not want to switch places with people new to the accessibility field – be it as designers, developers, or testers – in the coming years. We have a long transitional phase in front of us. This would be OK if WCAG 2 was a universally understood and applied baseline. But it is not. Most websites fail WCAG, and I don’t think that will change over the next years, also not with a new standard overnight.

For me, WCAG 3 currently feels like a big distraction, the candy you are not allowed to have for a long time. And then you need to develop tools, and teach the standard to people, and lobby for adoption. All while WCAG 2 is there and could be improved.

I recommend to always include brackets with the element names. You can differentiate attributes and values by using these words. Always include the word “value” when talking about values.

• First mention of an element: “<h1> element”
• First mention of an attribute: “id attribute”
• First mention of a value: “my-great-id value”
• Subsequent mention of an element: “<h1>” or “<h1> element”
• Subsequent mention of an attribute: “id” or “id attribute”
• Subsequent mention of a value: “my-great-id value”
• Avoid the use of “tag” when the whole element is the subject of the sentence, do only use “tag” when it is specific to the start or end tag. Always specify “start tag” or “end tag”.

(This post was imported from my micro.blog.)

The SC was deemed to not be AA-worthy. With the W3C process, however, items marked as at risk, which this SC was, can only be removed before publication of the standard, not altered. So changing it to a AAA criterion meant that there had to be a new Candidate Recommendation anyway.

The WG took that opportunity to change the order of the SC, too, as new AAA success criteria have always been inserted after AA success criteria. I’m not fond of the last-minute SC number change (it is now 2.4.13 instead of 2.4.11) but it can always happen. It’s one reason why I never refer to SC numbers when talking about proposed criteria in Editor’s or Working Drafts. I am not sure that this has ever happened during Candidate Recommendation phase, however. [^ Hence I used the SC numbers in the headings of a recent blog post.]

First, the good thing about the changed 2.4.13 Focus Appearance criterion: It reads really simple, and that is a good thing. To meet AAA, your focus indicator needs to be at least as large as a 2px thick around the perimeter of the focused element and have a 3∶1 contrast ratio.

Now, the bad thing about the change: The previous proposal of moving 2.4.7 Focus Visible to A level has been completely reverted. A basic, in any way visible focus is essential for keyboard users who do not use assistive technologies that create their own focus ring. It is such a basic accessibility affordance like having good page titles or having a consistent focus order, both SCs are A-level SCs.

It makes little sense to say that the order of the focused elements must be logical, but it does not matter to be able to perceive where you are in those elements.

This SC should have been an A-level SC from WCAG 2.0 back in 2008. That the Working Group has reverted a change that would not affect most people (as the general baseline is AA in laws and policies) but sent a signal on its importance is baffling to me.

But, the most outrageous issue is that what a “visible focus” stays undefined at AA level. Arguably, changing one pixel from white to just off-white satisfies that there is a visible change on focus.

This is the only place where, in an AA SC, the term visible is not defined. 1.4.3 Contrast Minimum (AA) defines is as 3∶1 for large/bold text and 4.5∶1 for normal size text. 1.4.11 Non-text Contrast (AA) defines it as 3:1 against adjacent colors.

Anything that is stronger than “visible” on an AA level would have been welcome. I proposed simplifications to the initial AA Focus Appearance SC, which were deemed as not strict enough (and at the same time overly strict) by the group last November.

The Group could have added an SC that defines what visible is: “At least a part of the focus indicator has a 3∶1 contrast ratio between the same pixels in the focused and unfocused states.”

Why is this important?

Good focus styles make the lives better of many disabled people and are generally a usability win. Many who do not think of themselves as disabled use the keyboard to navigate web pages. A visible focus is an essential affordance.

The other reason is that WCAG 2.2 is planned to be the final update for WCAG 2. The proposed new Charter for the Working Group puts WCAG 3 at the front, with WCAG 2 going into maintenance mode. And considering that the WG refuses to publish updates in the case of typos, I expect little maintenance on the actual specification.

As for WCAG 3, the Charter has an “expected completion date” of Q2, 2026. But the previous/current charter stated WCAG 2.2 would be done by Q4 2020 and WCAG 3 done by Q2 2023.

I don’t blame the Group for having deadlines slip in the midst of a global pandemic. But I take the expected dates with a grain of salt, especially as we are staring at a WCAG 3 Working Draft that has seen no updates over the past year. And it tries to re-invent accessibility conformance completely. I’ll not repeat that I think an evolution of WCAG 2 – a generally good standard that would need more frequent updates – would be a simpler approach. You can read about it here or watch my 75-minute presentation here[^ Feel free to skip to the WCAG chapter directly.].

But I don’t expect WCAG 3 to be ready before the end of the decade. And that means, gaps in conformance that have a real impact on users will be at least be unsolved for another decade, as it will take time for WCAG 3 practices to get developed. That is a lot of time during which we are basically OK with the rules of accessibility as they are. Maybe we should aim for better.

• Average errors per home page went slightly down to 50 errors.
• 96.3% of home pages still have easily detectable WCAG failures. That is only a decrease of 1.5% in four years.
• 96.1% of errors fall in six categories:
  • Low contrast text
  • Missing alternative text for images
  • Empty links
  • Missing form input labels
  • Empty buttons
  • Missing document language
• The use of ARIA (Accessible Rich Internet Applications) has increased a lot. And home pages that use ARIA are more likely to be inaccessible.

The shocking truth is, that we cannot make the web accessible at a rate of 5000 websites per year. There are gigantic Diversity, Equity, and Inclusion programs, and they barely make a dent in the actual accessibility of websites. Where are the commitments, where are the action plans? It’s just the home page, we should have shamed — sorry, encouraged — people to at least get their home pages in order.

Also, the 96% of issues that are found on websites? These are not new requirements. They all have been around since WCAG 1.0[^ Web Content Accessibility Guidelines 1.0] which was released in 1999 and will celebrate its 24th birthday in May. The same principles have been carried over in the 2.0 and 2.1 standards released in 2008 and 2018.

A quarter of a century and basic accessibility is not met by 96% of home pages. I find this fact embarrassing. Mostly as a web developer because fixing those six issues can be learned in a day. If you are a web developer who does not know how to fix them, read these two excellent articles from Hidde now: Post 1, Post 2.

But I also find it embarrassing for web accessibility. We should have better strategies to educate people about the issues, provide them with actionable feedback and make sure that issues are effectively addressed.

For other issues, we should explore how to minimize the impact on disabled people by using browsers to mitigate issues. A ramp built into a train will generally be more available than a situation where every stop needs to provide its own ramp.[^ Yes, this simplifies the maintenance and reliability issues of some built-in ramps.]

Mitigation for low contrast text could be done by the browser directly: Fixa11y is a browser plugin that detects low contrast text and adjusts it to meet minimum or even high contrast scenarios. If this was built into browsers, it would take the burden from implementors, and allow users to customize their experience.

But the browser cannot do everything. Alternative texts need to be customized and fit into the page and context where they are. Automated image recognition is getting better, but it is far from context-aware enough to rely on it daily. That said, it is technically possible to add a default, maybe very detailed description to image files, especially if they are package files. Those detailed image descriptions would travel with the file and be available as a fallback option in case no context alternative text is provided.

Empty links and buttons, as well as unlabeled form elements, should be part of the browser’s console error messages. There is no reason why JavaScript programming errors trigger messages, and accessibility issues do not. Tooling is bizarrely oblivious to accessibility.

Essential ARIA functionality must be transferred into HTML. ARIA needs to be a specialist tool that you only get out if you don’t have any other options. Many of the ARIA techniques are very intricate and for 90% of developers they should never be exposed to that kind of complexity and power.

In the end, we must guarantee an accessible web that everyone can use and adjust to their needs. This is the basic promise of the web, a promise that is broken every day.

Some people think it’s the standard, and if we quickly work on a version 3 of WCAG, all will fall into place. I don’t buy that. We have standards for almost a quarter of a century and people are unable or unwilling to follow them. Rephrasing the basic principles – that content must be perceivable, understandable, operable, and robust – will not move the needle towards an inclusive web. In the best case, web accessibility will drag on. In the worst case, we will have multiple standards to follow that have entirely unique ideas of how to test and measure accessibility.

And we have a good standard. WCAG 2 has its weaknesses, but meaningful evolution is possible if the Working Group wants it.

After many, many, years of trying to make the web accessible doing the same things, maybe it is time to re-evaluate. Take a look at the list of issues and develop a strategy on how to address each of them. Look holistically where these issues are introduced and how we can start to prevent them. The current strategy of “here are rules, deal with them, goodbye” has not worked, and the rules don’t go away while we remove the systematic issues plaguing accessibility.

I wrote about this topic before in Fix web accessibility systematically and spoke about it in my talk Web Accessibility is broken. It’s time to fix it!

Human problems need human solutions

At its core, accessibility is about people interacting with computers. Users take different paths with their computers to get to your content. Sometimes that route is through a screen reader, zoom software, voice interface, or switch controls. In other use cases, there are no specific accessibility features involved. In addition, there are many written and unwritten user interface rules that apply: Is user interaction from one operating system even understandable on another operating system? Can different accessibility APIs even represent a specific UI element?

This has happened before, with the Treeview component, which is rarely used outside its natural Windows 98 habitat. There is no rule against using it, but making it truly accessible instead of just conforming to some soulless specification is almost impossible.

Automated findings need human interpretation

Sure, finding issues can be a challenge. But the real challenge is how to address an issue. An automated tool can easily say that a <div> with a link role cannot be reached with the keyboard. But what the correct course of action is, might not be clear to the person reading the finding.

Usually, you want to replace the <div> with an <a> element, but in other instances, removing the role="link" altogether is the correct advice. Might some AI/ ML/ InsertBuzzwordTechnologyHere be able to figure this out and make a decent guess? Maybe at some point. But the reality is that the automation might give you wrong advice, which means it will look to the tool that you fixed the issue, but in reality you haven’t.

Automated testing is pretty basic

WCAG 2.0 is 15 years old this year. And while tools to aid exploratory testing[^ In accessibility, we usually call this “manual testing”, but I’ve learned a few years ago that QA testers use the term “exploratory testing” instead. As web accessibility testing includes many instances of exploring the content with different tools and (assistive) technologies, I have adapted that nomenclature.] have matured and gotten better to guide testers through what needs to be done, most automated testing is still very basic. Adrian Roselli compared his own exploratory testing to free automated tools in a blog post recently.

The results are not good. While Adrian found 37 failures against WCAG, the most failures any tool found were five. No tool found any AA violations, Adrian found 11. The tools can also provide warnings, which can be useful. But in my experience, the warnings can create more confusion, especially when the tool users are inexperienced.

While A success criteria (generally) have the most impact on disabled people, not finding any AA criteria is obviously a weakness. It clearly shows that you cannot rely on automated testing alone to meet the absolute minimum level of WCAG AA.

Efficient automated testing works best for preventing regressions

While I think automated testing tools are not good at finding accessibility issues and helping to remediate them, the tests can help with keeping a website or app accessible. Significant issues will crop up earlier when you have regular linting and automated testing for accessibility. This becomes even better if you can include best practice rules. Comparing to a known best practice will always be more useful than having a general purpose tool.

Might this get better in the future?

Maybe. It is hard to gauge the future of our community at the moment. On one hand, it looks like some aspects get easier to test, on the other hand, new requirements are introduced occasionally. And then there is room for interpretation of the rules and how to apply them. And that all does not take into account that the web is a magical, flexible medium that you can adapt to a plethora of things.

But manual testing is hard and expensive

That’s true. Deal with it. 😎

There is no way around doing a manual/exploratory test eventually. That is just the nature of the task at hand. And as much as you would expect a developer to know enough to check their code generally for bugs like performance and security, we also need to teach developers to do the same. It’s not that this would completely prevent the need for exploratory testing, but it would certainly prevent shipping the simple to recognize accessibility bugs.

Automated tools should run continuously and issues remediated immediately. That’s where these tools are useful. In all other cases, automated tools can be too hard to understand for users who are not accessibility experts. And once they have acquired enough knowledge to understand them, the users don’t need automated testing anymore.

Update February 15, 2023

Karl Groves published a blog post called “Automation is not the enemy”, where he specifically calls out the title of this article without linking to it (which is fair). As an automation nerd, I enthusiastically agree that automation is our friend. I automate the heck out of my life on an everyday basis. I have Stream Deck buttons that switch on and off different email accounts, depending on the work I do.

But, especially for accessibility testing, users of those tools must be aware that they are severely limited, which Karl also agrees with:

It is true that there are a lot of shortcomings when it comes to automation of something like accessibility testing.

Sadly, it bears mentioning that no automated accessibility testing tool on the market today can fully test for every possible accessibility challenge. In fact, some WCAG Success Criterion cannot be tested for using any automated means available now.

I’m not sure where his leap of understanding comes from when he writes in the following sentence:

That said, it is still irresponsible to act as though automated testing is bad and should be avoided.

Because I don’t think anyone has said that. At least I did not write this in my article. The fair summarization of my article is “automated testing tools have limits (hence they don’t on their own solve web accessibility) and people need to be aware of them”.

A while ago, a competing vendor started making the claim that their tool could find over 70% of accessibility issues, then made hand-wavy explanations of how they came to that conclusion. I decided to do my own research. What I found, based on Tenon’s data, is that my own findings from my blog post “What can be tested and how” from 2012 is still accurate – but that there’s a pretty big difference between “possible” and “likely”, and Tenon.io was able to find 59% of likely accessibility issues.

I don’t think any of this contradicts my post above. I explicitly say, “While A success criteria (generally) have the most impact on disabled people, not finding any AA criteria is obviously a weakness.” And yes. Adrian’s test is limited to one site only, but it matches my experience. Level A issues are generally more likely to occur than AA issues. As Karl points out, the lens though which you view results is essential. 60% of likely accessibility issues is good, but we can’t call this “accessibility solved” – and we all agree on that.

Automated tools have become better in recent years in other ways than how many errors they detect. Interoperability is one aspect, there is a W3C Working Group that makes sure that tools can use the same tests to interpret things similarly. That’s good. I don’t claim that there has been no development in these tools, just that they are limited. And those limits come from the way accessibility as a discipline needs to be viewed (a human problem with human solutions) and how the standards are written.

Finally, Karl makes the good point that automated tools that are regularly used by trained accessibility professionals can speed up, help, and supplement manual/exploratory testing. And I totally agree. Professionals use tools and know their limits and how to interpret results. But that doesn’t mean that the same tools can be given to non-professionals with the expectation of similar success.

Final note: I have recommended Tenon.io in the past to clients where I thought it was the right fit. I regularly tell people to use axe to verify their work. But I also say that they might need a professional that interprets the results or recommend best practices to solve issues, and advise them to reach out, if they are unsure about the results or how to address errors.

About the ratings

I judge the success criteria by different categories:

• Understandability: For me, this is the most important criterion for the success of an SC. If it is hard to understand, it will mean that people will have a hard time learning and internalizing the SC.
• Teachability: While this seems to be closely related to understandability, it is a slightly different aspect that I find critical. Sometimes hard to understand concepts can be easily taught.
• Testability: How much will this change affect testing. Is it a massive burden, or is it something that you can test with other tests.
• Impact: How much will this change improve the lives of disabled people?

All four categories will be graded on a scale of zero to five, where five is the best possible rating. Of course, this is far from scientific, but I try to explain my ratings in (excruciating) detail!

2.4.13 Focus Appearance (Level AAA)

What this SC does: 2.4.11 is supposed to make clear what “visible” means for 2.4.7 Focus Visible. It defines the area that the visible focus needs to cover and how much contrast there needs to be towards adjacent colors.

Rating: This success criterion is a mess. You can see the ambition of the Working Group to finally fix 2.4.7 Focus Visible, but the resulting SC just is not very good. And it hasn’t changed since September. It introduces four new definitions and has various sub-rules. There are different requirements for when the entire focus indicator encloses the UI component in question or when it only partly does so. Sometimes it must meet a 3:1 contrast ratio unless a certain thickness is met. There are no obvious fail cases this way and also no obvious pass cases because one pixel that doesn’t meet the 3:1 contrast ratio means that a different calculation needs to be used. This SC is still at risk and I wished it was either split up or replaced with easier to understand and test guidance. (More in the conclusion below!)

• Understandability: 0 — You can read this Success Criterion many, many times, and you will always find new ways to combine the different clauses which upend your previous assumption of what is a pass or a fail.
• Teachability: 0 — I think I can give most people a good overview on what any success criterion is and how to apply it in practice (be it an implementor or tester) in an hour. For this, I don’t even know where to start. I usually try to summarize a success criterion in one sentence and then spiral out into exceptions and particularities of an SC from there. Here, apart from “defines the appearance of the focus in many ways” I don’t even know where to start.
• Testability: 2 — This is generous. I think that the different descriptions will help to determine relatively exactly if something meets the SC or not. That said, it will be a lot of work to go through every focusable element and see if they meet the SC or if a vital part of the visible focus does not meet the SC. I would expect that this can add hours to some complex pages.
• Impact: 5 — Obviously, having a visible focus is super important. Having this guidance in WCAG 2.2 is long overdue.
• Verdict: 7/20

Update 7 February 2023

Alastair Campbell has published a post explaining the SC. I appreciate the blog post, but it does actually show what the issue here is. his examples are all clear-cut and isolated examples. It is a good introduction for implementers, but it does little for testers. I think this is exemplary by this quote:

For example, a 25 by 100px button requires an indicator area of 25+25+100+100 = 150px.
Technically we need to take off 4px for the corners as they overlap, so it is 146px. However, if you are relying on 4 pixels you have bigger problems. If it is that close, pick a different indicator!

As a tester, it is not on me to chose that. I need to measure it. And if there is a difference of 4px, I need to understand that. I would argue that, if 4px out of an area of 150px doesn’t matter, why insist including it in the definition. Why go through the length of defining a perimeter? The reason is that a CSS outline works that way, the four pixels in the corners are shared between vertical and horizontal borders/outlines.

So those four pixels matter a lot to make it easy to conform in simple instances. Because if we don’t account for those four pixels, the focus definition of outline: 1px solid black would not conform on a white background.

Testers must understand this. That’s why I say that this SC has very intricate new concepts testers must understand making a decision on conformance.

The next example shows a four pixel thick left line next to the text “Example 2”. The text is on a grey background. Considering that this example is about the perimeter rule, the whole height of the link or button is apparently set by the background color. With a star or a circle, the perimeter would follow the exact visual outline of the shape. Here, the faint grey background is counted as part of the shape. Would the perimeter apply only to the text height, if there was no background color? I think so (but I might be wrong). If that was the case, changing the background of a component from white to just off-white would change its focus indicator requirement.

Another example is “Easy to assess passes”, example 3. A white button with black text whose focus style is an inverted color scheme: black button with white text. It’s probably one of the most common examples of a good focus style. But there is nothing in the SC that screams that makes this pass obvious. It passes clause 2 as on focus, 100% of all pixels change color with sufficient contrast, which is more than the pixels needed.

Of course, I can teach those clear examples, but that is not where the rubber meets the road when doing testing and teaching. Even for the clear examples, I need to clearly rationalize why the elements conform. This is especially important when we get to learn new success criteria.

And of course these examples are isolated cases. What happens if a specific style does not meet the SC – even barely – in one case and does meet it in another. That can easily happen when the size of the element changes. What is sufficient in a menu in one language, might not meet the SC in a language with longer words. It adds a lot of complexity to WCAG.

I don’t think this SC will change. “It’s not that bad” is what I have been hearing for a long time now. I and others disagree, but it won’t matter. I think the best case scenario is that everyone will test for the obvious scenarios and then ignore everything that is non-obvious or close enough. And that will probably be OK.

Update 2 June 2023

In the WCAG 2.2 Recommendation Draft update from 17 May 2023 has been demoted to an AAA Success Criterion, which also meant moving it behind the Focus Not Obscured Success Criteria. So this goes from 2.4.11 to 2.4.13.[^ Yes, it’s confusing.] I have changed the headings, left the previous IDs in place (hashtag cool URIs never change) and I won’t reorder the SCs here.

It was also altered again, because why not.

In addition, 1.4.7 is back on AA level again. I guess a visible focus is not that important after all!

2.4.11 Focus Not Obscured (Minimum) (Level AA)

What this SC does: If something receives focus, it can’t be entirely hidden by website content. (Here, you just learned all there is to this success criterion.)

Rating: This is a needed SC. We often see that cookie banners or other messages are on top of focused content.

• Understandability: 5
• Teachability: 5
• Testability: 5
• Impact: 4 — This would have gotten a score of 5 if it was an A criterion. I think it’s simple enough to do that it should be a baseline accessibility requirement.
• Verdict: 19/20 — This is a perfect SC. Short, to the point, easy to understand and implement. More of this.

2.4.13 Focus Not Obscured (Enhanced) (Level AAA)

What this SC does: If something receives focus, no part of it can be hidden by website content.

Rating: This is a perfect step up from the AA SC with the same name.

• Understandability: 5
• Teachability: 5
• Testability: 5
• Impact: 3 — I think AAA is the right level for this SC, but I could have seen it as an AA criterion as well. As an AAA criterion, its impact is limited.
• Verdict: 18/20

2.5.7 Dragging Movements (Level AA)

What this SC does: Provide an alternative for dragging actions.

Rating: This is also a pretty straightforward SC. The only slight complication is the definition of what “dragging movement” is. Testing is all manual, but dragging is relatively rare and alternatives are usually pretty obvious. Well done!

• Understandability: 4
• Teachability: 5
• Testability: 5
• Impact: 5
• Verdict: 19/20

2.5.8 Target Size (Minimum) (Level AA)

What this SC does: Defines a minimum size for interactive elements (24px by 24px) with some exception when there is enough space around the element or when it is part of a sentence.

Rating: We had 2.5.5 Target Size on level AAA in WCAG 2.1 and having some minimum is certainly good. 24px is a little small for my taste, but it’s always hard to strike the balance here. What I don’t like is that the exceptions are worded differently between the two SCs and I would love to adopt the 2.5.8 wording in the renamed 2.5.5 Target Size (Enhanced) SC.

Teaching could be a little better as there are a lot of exceptions. The definition of target offset is outrageously complicated. (Basically, when two targets are next to each other, the targets can be less than 24px large, as long as the space between the side furthest away of one target is 24px to the nearest side of the second target). Testing can be done in general automatically, with manual reviews for the exceptions. The impact I rated relatively low because such small UI components are relatively uncommon.

Update 3 February 2023

After reading through more issues (particularly w3c/wcag#2972, w3c/wcag#2973, and w3c/wcag#2974) with target offset, I think I need to deduct one point each from Understandability and Teachability, as well as Testability. This is more complicated than it looks and while irregular shapes are rare, their testing will be a significant head-scratcher.

• Understandability: 3 (was: 4)
• Teachability: 2 (was: 3)
• Testability: 4 (was: 5)
• Impact: 3
• Verdict: 12/20

3.2.6 Consistent Help (Level A)

What this SC does: Requires that help mechanisms that repeat on multiple pages are in the same place.

Rating: This is a little nothing burger of a Success Criterion, as usually most mainstream website already meet this and it doesn’t elevate the need for good accessible help mechanisms. I think the name is misleading (similar to Consistent Navigation and Identification) because it is not the help that needs to be consistent, but its placement or order. So Consistent Help Position or something would make this much easier to understand at a glance. This SC has also a note on “same relative order” which explains what is meant with this phrase. Maybe this should better be a normative definition that can also be applied to other “same relative order” SCs?

• Understandability: 4
• Teachability: 5
• Testability: 5
• Impact: 1
• Verdict: 15/20

3.3.7 Redundant Entry (Level A)

What this SC does: Requires that users do not need to enter information again, when they have already provided that data.

Rating: The intent and the wording of this SC is pretty good, and I like that it is on the A level. It makes a lot of sense. It will improve data submission for everyone with a disability. The only ding is the short name, because it should say “No Redundant Entry”. But I won’t deduct points for that!

Update 4 February 2023

Patrick H. Lauke makes the excellent point that the impact of the SC is limited by the fact that it is scoped to the current process. Feels like this should have a companion AA SC that avoids that any users have to enter redundant information in any processes.

• Understandability: 5
• Teachability: 5
• Testability: 5
• Impact: 4 (was: 5)
• Verdict: 19/20

3.3.8 Accessible Authentication (Level AA)

What this SC does: Improves accessibility by avoiding cognitive function tests in password authentication flows …

Rating: … unless it is a cognitive function test that is covered by exceptions. And those exceptions explicitly allow the use of CAPTCHAs where you recognize objects. It does not define what the “objects” can be that need to be recognized. I remember that ReCaptcha asked me to identify fire hydrants, and none looked like German hydrants. I’m not sure if this is really a significant improvement for users with cognitive impairments. It’s also not specified that you need an accessible alternative for the CAPTCHA, tho that would be covered by other SCs, I guess.

Testing if some login flow meets this SC will be relatively cumbersome but doable. I expect significant discussions on what a “mechanism to assist the user” is. I don’t know how feasible it is to use content uploaded to the website as a form of authentication.

• Understandability: 4
• Teachability: 4
• Testability: 4
• Impact: 3
• Verdict: 15/20

3.3.9 Accessible Authentication (Enhanced) (Level AAA)

What this SC does: Improves accessibility by avoiding cognitive function tests in password authentication flows …

Rating: … but with fewer exceptions. CAPTCHAs are not allowed, and you cannot make the user identify content they provided to the site.

• Understandability: 4
• Teachability: 4
• Testability: 4
• Impact: 2
• Verdict: 14/20

4.1.1 Parsing (Obsolete and removed) (Level A)

What this SC does: Nothing! It has been removed as it is now obsolete with the modern HTML parsers.

Rating: In the end, removing this SC is the clear-cut decision that we need from the WCAG WG. Without institutional knowledge, many people interpreted “nested according to specification” that it required HTML elements to be “nested according to the HTML specification”, not to the XML parsing rules. Of course, the latter makes much more sense 😉

• Understandability: 5
• Teachability: 5
• Testability: 5
• Impact: 5
• Verdict: 20/20

Conclusion

This gives us the following scores for the success criteria, from best to worst:

• 20 Points
  • 4.1.1 Parsing
• 19 Points
  • 2.4.12 Focus Not Obscured (Minimum)
  • 2.5.7 Dragging Movements
  • 3.3.7 Redundant Entry
• 18 Points
  • 2.4.13 Focus Not Obscured (Enhanced)
• 15 Points
  • 3.2.6 Consistent Help
  • 3.3.8 Accessible Authentication
• 14 Points
  • 3.3.9 Accessible Authentication (Enhanced)
• 12 Points
  • 2.5.8 Target Size (Minimum)
• 7 Points
  • 2.4.11 Focus Appearance

What does that tell us? Not much. I’m personally disappointed that 2.4.11 Focus Appearance has not improved at all since September. I don’t want this Success Criterion to be removed, but it will also be a pain to implement. The Working Group can do better. Split it up in multiple SCs, try not to cover every edge case. There is an exercise going on where the Working Group tries to figure out if 2.4.11’s complexity and reliability. Maybe this SC can be removed from 2.2 and reintroduced in six months in a 2.3 update. Individual SCs should never hold up updates.

I’m really not sure what the best way forward is. On one hand, most of the updates feel OK as test criteria but don’t really push accessibility forward. Perhaps that is the strategy here. I think with good leadership, WCAG 2 has good guts to go for another decade. But the Working Group needs to be willing and able to simplify, clarify and modernize the standard.

I’m not a big fan of creating a major revision just for the sake of it. We’re only two versions into WCAG 2, and it held up well. I did propose fixing web accessibility in a more systematic way in 2021. I still think it’s important to re-evaluate how we want web accessibility to succeed.

Good stuff

• We have settled in to the new apartment, and it is still great and everything we could wish for.
• I started e-biking and spent over 250 km on the bike this year. While that does not sound much, considering that my fitness level is bad and the terrain here is quite hilly, I feel good about it. Biking helped me to get out of the house and explore the nature around the new apartment. Splendid! Unfortunately, the last few weeks of the bike season were tainted by an inner tube failure and now the need to adjust the back brakes. While I’m quite handy, doing something for the first time is complicated – especially if it has to do with brakes. I need those!
• After building the Space Shuttle Discovery last year, I really got into Lego building. It’s an obsession now. It helps me to do something with my hands and switch off my brain. I built the following sets:
  • NASA Apollo Saturn V
  • Doctor Who TARDIS (Yes, I bought this on eBay for a ridiculous price. Worth it!)
  • Vincent van Gogh - The Starry Night
  • Nintendo Entertainment System™
  • International Space Station (I had to get this before it sold out – and I’m glad I did!)
  • Holiday Main Street
  • Santa’s Visit
  • Orchid
  • XL-15 Spaceship
  • Optimus Prime
  • The Mighty Bowser™
• I read three books, which I enjoyed a lot!
  • Dan Moren’s The Caledonian Gambit and The Nova Incident, including the connecting short stories
  • Antony Johnston’s The Patrios Network
  • I want to read more… but there’s Lego to build and TV to watch, so I don’t really make time for it. 😉
• Speaking of TV: 2022 was a good year for TV. My highlights:
  • Severance (Apple TV+)
  • Mythic Quest (Apple TV+)
  • Slow Horses (Apple TV+)
  • For All Mankind (Apple TV+)
  • Moon Knight (Disney+)
  • Ms Marvel (Disney+)
  • She-Hulk (Disney+)
  • Obi-Wan Kenobi (Disney+)
  • Andor (Disney+)
  • Welcome to Wrexham (Disney+)
  • The Sandman (Netflix)
  • Jet Lag: The Game (Nebula/YouTube)
  • Doctor Who — Eve of the Daleks and Power of the Doctor are fun, and Legend of the Sea Devils happened, too! I’m looking forward to the new era!
• Formula E: I got a little bit obsessed with Season 8 of this motor sport. Electric cars are fascinating, and there is a lot of work going into finding out how to most efficiently use the battery’s power. 2023’s 9th season sees the new third generation car, too. And if it is true what I have seen so far, the World Championship will be a tough competition.
• Snooker: A lot of Snooker happened, too. With a lot of Drama, especially Ronnie’s seventh World Championship and Mark Allen’s success. It really is the sport that keeps on giving with the change of pace. Ultra quick, super attacking frames and long, tense safety encounters. Anything can happen. Brilliant!
• I also re-discovered microblogging and signed back up for micro.blog – you can find my microblog at micro.yatil.net.
• I was invited to two podcasts: Parallel and the German speaking Working Draft.
• Furthermore, I blogged quite a lot here. 15 posts sounds like a record in recent years.
• Working with Axess Lab, who I joined in March this year, is delightful. My colleagues are knowledgeable and insightful.

Not so good stuff

This year was mainly one thing, and that is exhausting.[^Honestly, after adding to the list above — I should not be that surprised. I did a lot!] I did pick up a lot of new hobbies and interests. And with the change in work, the ongoing war in Ukraine, and the lingering Pandemic, it was just much. But it was also a lot of fun to rediscover hobbies.

In addition, I feel the loss of some of my accessibility community. Firstly, I lost interest helping with and commenting on WCAG. It just felt like a waste of time. The WCAG 3 discussions didn’t feel productive for a long time, and WCAG 2 followed quickly after the release of the Candidate Recommendation Snapshot of WCAG 2.2 which felt not well thought-through. I have seen that some comments are getting addressed, but I can’t fathom being involved as much as I had been in the past.

The second community loss was through Twitter. It was a huge part of my communication and keeping up with peers. Mastodon and microblogging does help with it, but it’s certainly a change. I did blog about both, WCAG and Twitter, in November.

The third community loss is my public speaking community, especially the accessibility community. Due to the global pandemic, I did not travel at all and kept mostly isolated all year. This is a necessary precaution as a person with “preexisting conditions”. I could also not live with the thought that a frivolous activity of mine caused direct harm of someone getting sick or long COVID. Especially people who are interested in accessibility or are disabled.

I do understand that conferences have commercial requirements to fulfill, and after being able to move a conference for two years, that was just not feasible for many in the community. The world pretended normality and forced organizers to hold these events. These events invited accessibility speakers who felt the duty to perform.

That said, it left a huge feeling of distrust in me. How can I trust that a conference keeps me or my disabled peers safe during another health event? I can’t. And that accessibility-focused events happened, with the predictable result of COVID-19 infections, is a reason for grave concern for me. And it’s extra concerning when those events market themselves as “inclusive”, but “not for people with respiratory illnesses.”

I won’t say that I will never speak at conferences who had in-person events this year, but I’m not eager to do so as well.

What’s next?

I don’t have reason to change a lot. I certainly want to get more active on the bike and also tackle longer trips through flatter terrain in the spring. After all, the Radweg Sieg is not too far away. I will work on acceptance of the loss of the communities and concentrate on building new ones. It’s important, and it doesn’t happen on its own. Luckily, the The Incomparable member’s Slack has been a nice refuge.

I hope to keep up the blogging and also go deeper into some topics. I have been catching up on hobby-type activities over last year, and I expect that to continue a little. Life did consist mainly of work in many of the previous years, so I yearn for other activities.

Twitter was (is?) important to me.

Seeing it change over the years made me sometimes tired of it, but in the end it just felt like a net positive place for me to be. Of course, this has changed this week. The place was attacked, but not from random people, but by someone who is – for all intents and purposes – almighty on the platform. There is nothing we can do.

Being powerless in the face of a tsunami of uncertainty and populism is what really irks me about the situation. Twitter was never really run extremely well, but it looked like it improved successively over the last couple of years. Especially, accessibility features got better and better, and the team really hit their stride lately. Until they got fired.

Twitter has lost its way for me. At least, I’m unable to fully trust it anymore. Maybe it will get better, but I have currently little desire to post on there.

In addition, I am trying to give up helping to improve WCAG from the outside.

Over the last few months, requests for clarification and simplicity have been either ignored or actively argued against. The standard as it might be published sometime next year is half-baked. The Working Group has not even looked at many of the existing issues.

Simple typos or editorial changes get no acknowledgement, and only few people of the Working Group seem to care for any of the discussions. It feels like they have all moved on.

WCAG is important, and I’m sure that does not make easier creating updates for it. But the reality is that the Working Group does not have enough support (or they wouldn’t be as behind). What starts as simple clarification questions (“What does visible in SC 2.4.7 Focus Visible actually mean?”) often ends up as a hard to understand and complicated new Success Criterion in an attempt to please everyone. Adding “a change of x CSS Pixels with at least a contrast of 3:1 to its background” would probably have covered most use cases for basic accessibility.

And then there are several places where the language and the actual interpretation of the guidelines do not match. For example, SC 1.4.1 Use of Color reads:

Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.

If you think color is not allowed to “convey information, indicating an action, prompting a response, or distinguishing a visual element” based on the text, you would be mistaken. Color can be used as long as you change the lightness of the color. From the Understanding document[^ Or, as I started to call them, the “well, actually document”]:

If content is conveyed through the use of colors that differ not only in their hue, but that also have a significant difference in lightness, then this counts as an additional visual distinction, as long as the difference in relative luminance between the colors leads to a contrast ratio of 3:1 or greater. For example, a light green and a dark red differ both by color (hue) and by lightness, so they would pass if the contrast ratio is at least 3:1. Similarly, if content is distinguished by inverting an element's foreground and background colors, this would pass (again, assuming that the foreground and background colors have a sufficient contrast).

Changing the word in the success criterion to “hue” instead of “color” would clarify this right in the Success Criterion text. But that seems too easy.[^ One argument against those changes is “backwards compatibility”. But backwards compatibility for me is not making things unchangeable. Such clarifications would only introduce minor changes from the previous version, often not requiring a change to websites at all. Many would be more precise than before, so a subset of the previous broader rule. And even if SCs get more strict over time, that is a good thing, it is also why new SCs are added. To make the web more accessible.]

Now, I don’t want to dig up those discussions again, and I certainly don’t want to throw shade at the WCAG WG. It does what it is chartered to do and has put these rules on itself. But it also means it is at odds with my personal goals, which has always been to make WCAG and related resources as easy to understand and as practically useful as possible. I did that inside W3C, and I tried to keep it up from outside.

However, over the last few weeks since the WCAG 2.2 Candidate Snapshot release, it became even more clear that there is no interest for this work. Minor requests to clarify wording draw outsized discussions. And not because the clarification would change the definition, but because “this is understandable enough if you read it right”.

I’m exhausted and sad. Because both Twitter and WCAG WG are squandering the potential to make the world a better place. Or at least make their own product the best it can be. At Twitter, one person wreaks havoc by making reckless changes. At WCAG WG, the self-imposed rules make it hard to adapt to the modern web. And early WCAG 3 drafts also show similar issues because of that mindset.

Anyway, I think the demise of Twitter has me realize at which places I spend my time and which give me joy. So I’m stepping back from commenting on WCAG 2. I already made that decision for WCAG 3 earlier this year due to a hostile environment. Instead, I will focus on teaching accessibility in simple, understandable, and clear terms. Accessibility for everyone.

If you want to read updates from me, see my microblog which largely had replaced Twitter for me over the last months anyway. You can even follow me through Mastodon or on micro.blog. There is a newsletter where I send the occasional email, and a way to support my work.

Now, because it is such a distributed system, the accessibility around the Fediverse is not super consistent either. But there are all the important foundations there, including the possibility to add alternative text for images.

Mastodon is a good place to dive into the Fediverse as it mimics Twitter quite closely: Followers and Following, Boosts (like “Retweets”), and Stars (like “Likes”). If you want to sign up for a disability/accessibility friendly instance, I can recommend toot.cafe, which tries to be as inclusive as the underlying software allows. There is also dragonscave.space, which is run by blind admins[^ via Robert Kinglett].

Sarah Higley has a very good step-by-step introduction on how to sign up to Mastodon, including server recommendations.

I, personally, have used micro.blog in the last couple of weeks, which deliberately does not support most of the standard Twitter and Mastodon functionality. I can’t even see who follows me. My toot.cafe profile still exists, and I’ll likely keep it (because it looks like it is easier to find for people), but it looks like it won’t be my primary way of posting in the future.

Should you join the Fediverse?

Yes, but not for the reasons that you might think of. It’s important to have options. And locking oneself into one social network is never good. Options are. Twitter has helped the web community to grow together like no other social network before. But it is in the end a closed system, which is antithetical to the web.

By opening a profile on Mastodon or somewhere else in the Fediverse, you can participate in more diverse places than before. And they all communicate with each other. It’s powerful, and if there is a new boss in your instance who brings a sink into a building for no reason, you can switch to another instance (with some issues).

Some accessibility people on the Fediverse:

Discovery can be hard on the Fediverse, but once you have an account, following and interacting is pretty straight forward. Here is a list of accessibility people that you can follow to get started:

• Me, Eric Eggert: @yatil@yatil.social
• Erik Kroes: @erikKroes@mastodon.social
• Kilian Valkhof: @Kilian@mastodon.social
• Svenja: @svenja@chaos.social
• Markus Herrmann: @marcus@mastodon.social
• Nina Gerling: @NinaGerling@mastodon.social
• Moritz Gießmann: @MoritzGiessmann@mastodon.social
• Joschi Kuphal: @jkphl@mastodon.social
• Matthias Ott: @matthiasott@mastodon.social
• Matthias Pfefferle: @pfefferle@mastodon.social & @pfefferle@notiz.blog
• René Stalder: @renestalder@mastodon.social
• Jeff Bigham: @jbigham@hci.social
• Rob Whitaker: @Rwapp@mastodon.social
• Michael Spellacy: @spellacy@a11y.info
• Saptak S: @saptaks@toots.dgplug.org
• Aaron Stephenson: @azzoor@mastodon.social
• ruben nic: @rubensandwich@mastodon.social
• Rachele DiTullio: @racheled@mastodon.social
• Jo Spelbrink: @joville@mastodon.social
• Eric Bednarz: @broomwagon@mastodon.social
• Melly: @melly_maeh@fedisabled.social
• Marco Zehe: @marco@chaos.social
• Adrian Roselli: @aardrian@toot.cafe
• Stéphane Deschamps: @accessiblestef@toot.cafe
• Heydon Pickering: @heydon@mastodon.social
• Dennis Lembrée: @dennisl@mastodon.social
• Scott O'Hara: @scottohara@mastodon.social
• Laura Kalbag: @laura@mastodon.laurakalbag.com
• Julie Moynat: @juliemoynat@mastodon.social
• Jeff Knaack: @knaackbuilt@mastodon.social
• Angie Radtke: @AngieRadtke@mastodon.social
• Anna E. Cook: @annaecook@mstdn.social
• Andrew Hedges: @segdeha@mastodon.social
• Núria Peña: @nuriapenya@mastodon.social
• Erik Vorhes: @erikvorhes@mastodon.social
• Laura Carlson: @laura_carlson@mastodon.social
• Peter Grucza: @pgrucza@toot.cafe
• Sarah Fossheim: @fossheim@mastodon.social
• Aaron Gustafson: @aarongustafson@toot.cafe
• Joe Humbert: @joehumbert@mastodon.social
• Mike 麥 Mai: @mikemai2awesome@mastodon.social
• Wendy Reid: @reidmore@mastodon.social
• Winnie Bosibori: @MissB@mstdn.social
• A11yAlicia: @A11yAlicia@mastodon.social
• Anne Bovelett: @bovelett@wpbuilds.social
• Raul Krauthausen: @RaulKrauthausen@mastodon.cloud
• Ronny Hendriks: @toegonline@mastodon.social
• Robert Kingett: @blindscribe@writing.exchange
• Hidde de Vries: @hdv@mastodon.social
• Meryl Evans: @MerylEvans@mastodon.social
• Daniel Mclaughlan: @straydogstrut@mstdn.social
• Sandrine: @fedbysandrine@mastodon.social
• FreeXenon: @FreeXenon@mastodon.social
• Ben Myers: @ben@a11y.info
• Beatriz González Mellídez: @b_atish@a11y.info
• Steve Sawczyn: @SteveSawczyn@mspsocial.net and @SteveSawczyn@micro.blog
• Arthur Rigaud: @arigaud_ca@a11y.info
• Marjon Bakker: @marjon@a11y.info
• Iacobien: @iacobien@mastodon.online
• Glenda Sims: @gwitch@mastodon.social
• Tristan Bussiere: @tristan@noc.social
• Jayme: @hippyjo@c.im
• Steve Woodson: @stevenwoodson@mastodon.online
• Todd Libby: @todd@a11y.info

If you want to get on the list, ping me on the Fediverse. My handle is @yatil@toot.cafe. I check that accounts are accessibility related.

Note: RelayFM. Parallel’s podcast network, supports St. Jude Children’s Research Hospital in their fight against childhood cancer with the annual donation drive.

Listen to the episode.

Listen here.

That said, most websites do not implement dark mode, so having a browser plugin like Noir or Dark Reader is necessary anyway.

A few weeks ago I read through Hidde’s blog post on his dark mode toggle implementation and that gave me the impetus to change this website to support dark mode, too.

First, I was thinking of just copying his solution, but binary dark mode toggles have an important caveat: What happens when the user changes their system settings?

You can either not follow the user’s setting and keep their choice, or, you can adapt with the system. Hidde looks for the change event in the dark mode media query and then adapts to the system preference. However, that only works if the website is open. If the website is closed, there is no way to update the data on what theme to use.[^ As I write this I realize that a Service Worker might be a way to do it, but that feels like an overengineered solution…]

Essentially there are three modes that should be respected:

• Follow the system setting at all times.
• Use light mode all the time, even if the system is in dark mode.
• Use dark mode all the time, even if the system is in light mode.

Looks like a 2-way toggle is not going to cut it. And while I briefly thought about a tri-state button[^ Urgh!], there is only so much information that you can convey through one button. I looked around and Hidde’s post already had the Firefox settings which showed “System theme”, “Light” and “Dark” with radio buttons. And macOS is doing a similar thing in the system preferences[^ Until macOS 12 Monterey at least, macOS 13 Ventura introduces a new preferences app, which has been rated “meh” so far. Let’s hope the best for improvements during the beta.].

When in doubt, I always prefer to be clear instead of clever, so my preferences button in the top right follows about the same principle. I use the new <dialog> element to put up a dialog that lets users choose their theme. A nice advantage of using a dialog is that users can get a preview of the changes and can then decide to save their choice or cancel and use their previous choice.

Of course there are a few caveats with this solution, not last the one Hidde also mentions in his post: To make it work reliably, I need to duplicate my variable declarations in my CSS file:

:root { /* Default light colors */ }

:root[data-theme-preference="light"] { /* Light theme selected */ }

@media (prefers-color-scheme: dark) {
  :root { /* System dark mode */ }
}

:root[data-theme-preference="dark"] { /* Dark mode selected */ }

The JavaScript is basically equivalent with a lot of what Hidde does, apart from the theme preference also supporting the value system. I also added a short inline JavaScript right after the opening <body> tag that applies the theme data attribute as soon as possible on page load. As my JavaScript is in a separate file, you could have gotten a flash of white before the dark mode kicked in.[^ That makes me wonder, what if we could use localStorage in media queries? For example: @media(localStorage("theme-preference"): dark)? That would be useful!]

I would agree with Hidde and Bramus that browsers should offer users choice between themes (and let’s extend it beyond light & dark, please! Despite the title of this post, this is not Star Wars!)

A tweet from my friend Nicolas Steenhout reminded me of one issue I often run into with clients: They ask for how to best test their sites in popular screen readers and I routinely name the ones most often used. That includes the most named “Primary Desktop/Laptop Screenreader”, JAWS.

Nic is correct: Here in Germany it is the same picture: A long list of dealerships[^ Some of these dealerships even have accessible websites!][^ And yes, the German Freedom Scientific website still uses tables for layout.] but no way to purchase online, let alone naming a price.

The US website has prices and even “buy now” buttons. A personal license costs $95/year if you are using your computer non-commercially. $1285 allows you to use the current version of the screen reader commercially, too. (For example to work, which the “J” in JAWS stands for!)

Freedom Scientific seems to make it hard on purpose to get their software outside of the US. It’s so complicated that I have rarely seen someone outsde the US actually include JAWS in their testing. Some people use the 40-minute demo version as a work-around, but that does violate the terms of use.

I actively advice users to test in alternative screen readers first: NVDA is a great free alternative for Windows. Mac OS users can use VoiceOver for testing. And usually, in 95+% of use cases, that is totally fine: websites and applications working in those browsers will also work in JAWS. And of course the needs for accessible websites are much broader than tailoring your app to specific screen reader and browser combinations.

But when you have very complex UIs that warrant throurough testing, it would be so much easier to also test with JAWS. But the hassle provides an unnecessary barrier for these people who want to do the right thing.

And yes, Freedom Scientific’s sibling company[^ It might be worth noting that Freedom Scientific and TPGi are brands of Vispero, which is one of the largest accessibility companies on the planet that engages also in testing and consulting. Technically, we’re competitors in the same market, but of course they are huge.] TPGi has the JAWS Inspect product, which shows the speech output as text which can be helpful in some situations. But without real screen reader interaction, its results are limited. And interactive scenarios are exactly the situations where using the real thing matters.[^ Also the price of JAWS Inspect is apparently “Schedule a Live Demo with us”.]

It’s easy to see how limiting access to their software limits testing which in turn makes it harder for their users to get to tested sites. It actively produces a worse outcome for their clients.

In addition $1285 per JAWS license version (so roughly every year) might not be affordable by many accessibility professionals, especially those who start out or are self-employed.

Freedom Scientific’s goal should be to put JAWS into as many developer hands as possible, because if websites work best in JAWS people who need screen readers will chose the commercial product on the market. Make it easy to rent JAWS on a virtual machine by the hour. I’m a happy Assistiv Labs customer[^ This post is not sponsored. But cough see yatil.net/support. — Update: After publication of this blog post, Weston from Assistive Labs became a supporter. Thank you!] and the ease of having a Windows screen reader on hand has transformed my work.

Please, Freedom Scientific, set JAWS free[^ Not like in “free beer”, more like in “Freedom Scientific”.] and make it easily accessible, for developers and for users.

The whole reason text-overflow exists is to specify the behavior of text once it flows over the container. There could be with and height constraints for a block. Using overflow: hidden makes sure that there is no overlapping text, but it cuts off the text abruptly. Text-overflow: ellipsis[^ And other, less well supported values.] allows to at least have an indicator that text is missing. But there is no way to make the hidden text visible.

In addition, text-overflow: ellipsis only works on one line text. That means that, to use this technique, you have to constrain the text to one line by using white-space: nowrap. MDN has a good example of the behavior.

There are a few legitimate use cases for this technique. For example, you might have a table with titles and descriptions. To preserve more space for the title, you constrain the description to one line on small viewports to the one-line and you repeat the description on the detail page for this item.

However, I often see it used on items like buttons or even form labels to make them look nicer(?) or when aligning them vertically. But once you change the viewport or resize the text, the end of the text disappears.

This is not the right thing to do. Even if your button might need to accommodate words like “Wagenstandsanzeiger”, seeing “Wagenstan…” is not going to be clear to users. It would be much better to hyphenate the word (using hyphens: auto[^ It would be really neat if Blink would finally support languages other than English here.] or ­ entities) instead.

And for the visual design: Inline flex and grids give you a lot of control to align text and icons, for example. Don’t constrain the content to fit your design, make your CSS flexible to handle longer words gracefully.

While these two success criteria seem related, they cover different use cases.

1.4.4 Resize Text

This success criterion that was introduced with WCAG 2.0 on level AA covers text resizing without assistive technologies. The requirement is that, except for captions and images of text, text can be resized up to 200% without losing content or functionality.

Note how the success criterion does not specify a specific method to reach this state of two times the font size. As long as the way to resize the text is “accessibility supported”, it is a valid way to conform to WCAG:

• Resizing only the text (classic text resizing)
• Zooming the page using browser features (viewport resizing)
• Changing the viewport by changing the display resolution
• Providing an on-page text size picker

Of course some ways are better than others and adjusting the viewport to resize text is frequently the most consistent way to do it, especially on websites that have been implemented in a responsive way.

That said, this SC is relatively permissive. As long as the text does not get completely lost (for example through overflow: hidden or text running into each other or behind other objects), your layout is allowed to break. And, more importantly, this success criterion gives no guidance on scrolling. It totally conforms if your website grows to twice the width and height when resizing the text to 200%, even if that means horizontal scrolling.

1.4.10 Reflow

Reflow was introduced to support users with low vision to easier navigate zoomed-in experiences by giving them a viewport size that – guaranteed – would not scroll horizontally. Reflow has nothing to do with resizing the size of the text at all.

It specifies that the content can be presented in a way that only requires scrolling in one direction at 320px for content that scrolls vertically (up and down) and 256px for content that scrolls horizontally (left and right).

There is an exception for content that requires two-dimensionality to be understood, example tables, maps, or some charts.

The reason for picking 320px/256px have been of practical nature. Firstly, 320px is a very common viewport width for smartphones. Secondly, if you use a desktop browser on a 1280px wide monitor and zoom in to 400% the width of the viewport is quartered internally in the browser… to 320px.

Using browser zoom on a desktop browser is functionally equivalent with changing the width of the viewport. Zoom to 200%, your viewport width halves.

How do these two success criteria work together?

From a desktop view, if you meet Reflow, you almost certainly also meet Resize Text. Even if your media query uses a lower font size for mobile devices, it would need to be very small to fall under the 200% threshold.

If your base font size is 16px, 200% is 32px (and note that these are real on-screen pixels, not CSS pixels dependent on your viewport here). A 8px size font in the 320px view would still meet the requirement of Resize Text. And Reflow has no requirement that the resulting text size needs to be at a certain size.

That said, once you are on a mobile viewport, you still need to be able to resize to 200% without losing any information (but scrolling horizontally is then allowed).

So… how is this supposed to be tested?

Resize the viewport width to 320px by 256px. Scrolling of the web page needs to happen in only one direction at a time. It is allowed to have sections of the page scroll into the other direction, but it must stay inside the viewport. For example would it be permissible to have a horizontal card area on an otherwise vertically scrolling page, but only if all information is visible in the viewport without being required to scroll in two dimensions.

Bump up the text size to 200%. You can do that through further zooming to a 160px viewport or resizing only the text. Important is that the resulting font size is 200% of the font visible on screen. (Note that the SC does not require that the text resize matches the setting. As long as you can eventually get to 200%, it is permissible, even if that means using the browser setting to 300% because a media query is using a smaller font size in the middle.)

In practice

Practically speaking, these success criteria are usually unproblematic, especially for modern, responsive websites. Yes, mistakes happen, and sometimes there is content that gets removed on smaller viewports. Or some CSS goes wrong when actual, real content meets it.

It can be tricky in complex web applications, especially if no mobile version exists or the mobile version removes content/functionality, as that is not allowed.

That said, text resizing in browsers is well supported (remember when Internet Explorer refused to resize text specified in pixels?) and the profileration of CSS Grid and Flexbox techniques for layouts makes it often less likely to break, compared to the float-based layouts back in the days. And web developers have learned to adapt better to different viewport sizes over the decade of responsive web development, which has brought a huge increase in accessibility in that area.

More content like this?

Support me on Steady and get blog posts like this in return!

Now, I’m not the most active person, especially through the last two-and-a-bit years of pandemic life, so a regular bike was out of the question. I just know myself too well, that I would lose interest if it was not fun to do. And honestly, the main reason for getting a bike is to have some fun. Also, to be flexible for running errands instead of doing everything on foot. But mainly to have fun.

Mobility options

When moving last year, we picked a spot that would allow us to stay car-free. Cars are expensive, bad for the environment, and take up a lot of space. There is a bus stop with hourly service down the street that can get us to the train station that itself is only a 30-minute walk away. The next supermarket is a 10-minute walk away.

I’m very baffled that so many people here are car-dependent, but then I don’t have to go to work as I work from home, and connections can be time-consuming if you go by public transport. Hourly services are just not going to cut it there, and I don’t think there are individuals to blame for it. The whole system of transportation is designed in a way that makes owning a car the easy and cheap option (cheap mostly in time, not necessarily in money).

I thought about many options for allowing us (2 adults) to have some more freedom for moving around. Getting an electric car, I considered. But even leasing it for a couple of hundred Euros a month would be a waste. We just don’t have to travel longer distances that often. Also, there is no way to charge in the garage, so you’d have to go and charge at public chargers every few days. It made any electric vehicle that is impossible to connect in the apartment unattractive.

With a car out of the question, I looked at individual transportation options. And a bike was the natural answer. For getting the two of us to some place, a combination of walk, rail, and taxi would be sufficient.

Picking a bike

I had assumed picking a bike was easy, there is not that much variation in bikes, right? Well, wrong.

After seeing Stéphanie Walter’s RAD bike, I got a particular interest in those bikes. They look good and as they also have a cargo option. I was interested in a cargo bike because getting groceries and hurling around other things might be a good use of a bike. Over the weeks, I realized that having a super specialized bike like this would certainly be limiting for general bike hikes. So I waned off the thought of the cargo bike and looked more at general purpose bikes like the RadCity 5 Plus.

There was just this one problem: The payload capacity.

In contrast to non-e-bikes, e-bikes have a stated payload capacity. And for this heavy guy, 125kg just wouldn’t cut it, especially when adding groceries to it. Now, the likeliness of the bike just going kaputt because of this is probably very, very low. And still, I have seen many heavy people ruin bikes because they were not built for them. I did not want to make that mistake with something that was many hundred Euros.

So, my quest to get an “XXL bike”, as they are frequently called in Germany, started. This turned out to be much more complicated and in the end also significantly more expensive than initially planned.

Honestly, the high price point almost made me not buy a bike. Sure, a non-e-bike is a commodity by now, a status that e-bikes generally don’t have yet. And while there seems to be good competition in the space, there seems to be a few price floors that are just hard or impossible to crack.

The bike that I decided in the end, the GIANT Explore E+ 2 (2021), a name that rolls right off the tongue and I totally had no need to look up just now, has some features that I think made the higher price worth for me, in addition to the 156kg weight limit.

Generally the quality of manufacturing in that price class seems to be much higher than on cheaper bikes, for example almost all cables run inside the bike instead of outside of it, which hopefully protect them better from wearing out.

I know that there are no-name brands and probably cheaper options with a similar quality, but the good conscience that you can go to a store and they have probably heard of the GIANT, a literal giant of the industry, is reassuring for me as a first-time e-bike user.

That said, even finding out what different bikes from the same manufacturer had to offer, and what their similarities and differences were, was excruciatingly difficult. All bike manufacturers have convenient comparison functionality but the jargon used just makes it super hard to understand if there is actually a (meaningful?) difference between two features or spec items.

It probably would have cleared up really quickly in an in-person showroom, but trying to buy something online, it felt unnecessarily complicated.

And then there are the bike categories and names themselves: Even inside GIANT, there are different bike types (which makes sense), but then there is a E+ 1 and an E+ 3 version, which have all different numbers of gears and some changes in the displays and UI. From how I understood, the numbers are levels, so 1 is for the most proficient riders and 2 is for medium and 3 is for entry. But I might be very wrong about this.

It does not help that the 2022 and 2021 models are displayed on the website with the same names and very similar images. It took me far too long to figure out that the one with the 200 € cheaper price tag was last year’s model, and a third party site (where I ultimately bought the bike) that stated that there are basically no changes.

OK, so how is the bike?

First, huge shout out to Zweirad Gollmann who had the bike (and at a slight discount) and after placing the order sent me a message to double check my height fit for the bike, so I would not get a too large or small bike. While I had read up on it before and was confident to have made the right choice, this made me very confident that I had made the right purchase decision.

They even asked if they could put on the lock I bought with the bike, and they did so for free.

The bike arrived a few days after ordering it, setting it up was super easy, just aligning the handlebar and attaching the pedals and off I went. Well, almost. While I had taken the battery for charging when I received the bike, it took about 30 minutes to install software updates.

As I have alluded to above, I did get the previous years model, so I guess newer models come with more recent software that hopefully needs less updates. That said, I could have gone for a ride without installing updates at all, but that is not really how I roll. (Pun intended!)

The bike rides wonderfully. I have mostly used the Smart Assist, or Auto, feature which supports you depending on how much you pedal. It feels very natural. Of course, I did try all the different assist modes, and they will be handy in different situations. I also rode on a flat street and switched off assistance completely and the bike still rode well.

Range anxiety is not a problem for me – my rounds are currently about 5km long. One reason is to get used to driving a bike again, getting acquainted with driving on roads (which I basically never did and is only an option here because of the light traffic), and to gradually get fitter.

So, any downsides?

Well, of course there are some. The app and software integration is pretty mediocre. That’s OK, I rather have a great bike (and this is one) with mediocre software than a mediocre bike with great software. What irks me most about the app is that it is only so useful. I can get all information from the bike, like the current battery level, when I’m in bluetooth range and I can also track my rides in the app. But that means that I have to have my phone out and prepped whenever I hop on the bike.

Planning a ride – which I have not done yet – is also only possible while being paired to the bike. As my bike is in my garage (which finally got a use!) and I am not planning my rides in the garage, but in my living room, it is basically a feature that does not exist for me. Depending on bluetooth range to the bike for this functionality is baffling to me.

The app’s view and use of Google Maps is also not too great, there is little bike-level information there and while there are a lot of graphs, none of them seem helpful to me. (But that might be a side-effect of being a novice rider.) It can also only export to Strava, at which point the question is: Why not use Strava directly? The app has a couple of nice features, like detailing how much support you got or how much battery was used.

I enjoyed the detail of the app changing color scheme with the dashboard on the bike when using different assist modes. Eco is green, trekking yellow, and sport red. That is a nice touch.

Also, I felt that I overextended myself during my first longer ride. You just can’t help and get the impression that you are more fit than you actually are while riding, but you still have to put in quite some pedaling work. And without warm-up and pedaling being a way of movement that I have not done for a long time, I was very sore for a couple of days. I probably should have ridden lower gears and/or higher assist, but it felt OK during the ride.

Last, but not least, expect to need a lot of additional accessories. A bike helmet, of course. (If your last one, like mine, sits on a shelf for about 8 years, it is probably a good time to replace it. I certainly did.) I got a handlebar mirror to have some visibility to the back, and how low the handlebars are is probably the biggest drawback of not having a Dutch-style bike, so visibility is still not great. I also got some penniers for the cargo part of the bike. I think they will work well. The bike uses an MIK rack mounting system which makes attaching and removing them very easy. A water bottle mount and a water bottle for hydration is also a must-have.

All in all, I can’t wait getting fitter and steadily increase the radius of where to bike to.

Diversity in May (Mangfold i mai) – ARIA Live Regions and User Preferences

For NAV, the Norwegian Labour and Welfare Administration, I’ll be holding two sessions for their “Diversity in May” series of events.

1. Workshop: We’re ARIA Live! (May 3, 2022, 10:00-11:30)
   A deeper dive into ARIA live regions, their alternatives, and particularities. (This workshop is NAV internal, registration for NAV employees is available on the website.)
2. Talk: Respecting User Preferences on the Web (May 13, 8:30–9:15)
   Allowing users to set their preferences and respecting them on websites is essential for accessibility. In this talk, that is updated for 2022, I’ll talk about which user preferences exist, how to implement, and how to test them. (This talk is open to everyone.)

AccessU 2022 – Web Accessibility is Broken

Knowbility’s AccessU 2022 has a different format this year, with asynchronous sessions being released on May 5th, 2022 and Questions and Answers during the “official” conference time between May 9 and 12.

In my brand-new talk, “Web Accessibility is broken. It’s time to fix it.”, I look at the system of web accessibility and what makes it so hard for web developers, designers, and managers to achieve. And then I have a few modest proposals for how to fix the system so that we get wider implementations and a higher overall standard.

You can buy tickets for AccessU 2022 here.

Talking at your conference or holding a workshop for your team?

Drop me an email if you’re interested in me holding these talks or similar talks and workshops for your team or at your conference. Please note that due to the ongoing pandemic, I’m only available for remote opportunities in 2022.

Knowbility picked up and supported my W3C/WAI work when EU funding dried up in 2016 with 50% of my time. With the rest, I supported the Knowbility team, worked with Knowbility’s clients and did trainings and audits. I also supported the “Community Programs”, the common good part of the Knowbility nonprofit with tech support, especially around the AccessU conference.

Oh, the conferences. Knowbility made it possible for me to visit and speak at several CSUNs and AccessUs. The amount of experience that I have been able to collect is invaluable.

That also continued when I took over the mantle as “Tech Team Lead” and later “Director of Accessibility Services” in 2020 after leaving my W3C/WAI duties. I was asked to lead the team and happily agreed. While leading a US-based team from Germany wasn't easy, my colleagues seemed to appreciated my leadership style. (At least that’s what they have told me. 😉)

Working with a nonprofit like Knowbility means that you often work with clients that are in there for the “right” reasons. Not because they are sued or want to have the shine of being accessible, but because they believe in accessibility. We worked hard with some clients to guide them from their initial audit to a more in-depth working relationship with Knowbility where they were able to build up more and more competencies in-house.

Another tent pole of the work with Knowbility is the notion that Knowbility is two things: community & education.

This is the approach we tried to get to with every audit: Make sure that the audit report could be used as a learning and educational tool, and treat the clients, which have all different business pressure around making their product accessible, as part of the community.

In contrast to other accessibility services companies, our reports tried their best to give actionable advice and hands-on guidance with enough context for readers to learn, but sufficient clarity to not have too much nuance overwhelm them. It’s always a balancing act, and we did work hard to meet those goals.

I want to thank everyone there. First, and foremost, Sharron Rush, Knowbility’s founder. Thanks for believing in me and hiring me. And a special thanks to the Team I had the pleasure to serve as a lead. Thanks to Becky, Emily, Alicia, and Francesca for working with me the longest. Your support and how you worked as a team made it effortless for me.

Thanks to Ron, Toma, Kyo, and Iain who are continuing the good work in services at Knowbility. Thank you, everyone in community programs and other functions who keep the heart of Knowbility beating. You know who you are.

I am incredibly proud of the work we did over the years: Improving flight booking to make it more accessible, fix accessibility problems in online learning tools, advise fashion and media companies on how to implement accessible and inclusive practices. We helped cities to serve their inhabitants better, made dashboards accessible, and convinced clients to do the correct thing instead of using overlay products.

Despite being such a small place, I am convinced that we have moved the needle in accessibility for millions of people, and probably many billions of interactions. And we trained – directly or indirectly through reports and meetings – hundreds of web developers, designers, and project managers.

I wish Knowbility all the best for the future.

For me, I’m excited to get my evenings back and hopefully a better “work-life balance”. Working and being responsible for a team in a different time zone is hard, as there is so little overlap for proper coordination and guidance.

I’m looking forward to new challenges with Axess Lab, who I decided to contract with from March 1st.

The character limit for alt text is 125 characters, which is short, but just do the best you can.

Keep your alt text fewer than 125 characters. Screen-reading tools typically stop reading alt text at this point, cutting off long-winded alt text at awkward moments when verbalizing this description for the visually impaired.

Terrill Thompson did create a test page for it and documented his results: No screen reader cut off text altogether. JAWS – and I have tested this with a more recent version of it as well – will split up the alternative text into multiple graphics with shorter alternative text.

Screen readers do not just hide the rest of the text.

Additionally, I am pretty sure that the cut-off mentioned in Firefox does not exist anymore. At least I did not come across any truncated alternative texts.

My best guess is that some people have observed JAWS’ behavior and assumed that the text was truncated where it was only split up.

Alternative text best practices

I helped write a whole tutorial on images, so I don’t want to go into the details here, but the general rules are:

• If an image meaning or shows something, it needs alternative text.
• Alternative text depends on the context and usage of the image.
• Describe the image as succinct as possible, but also as detailed as needed.

Writing alternative text is an art more than a science, and sometimes you’ll leave out essential information. My litmus test is “would I picture an approximation of the image when it was described to me over the phone using the alternative text.”

A few years ago, I talked to a person new to accessibility about their view that data tables were terrible for accessibility, especially for people using screen readers. It took a bit of time until I realized why they thought this was the case: The person had used a screen reader to test their site, but only knew about the basic functionality. Navigating tables, however, comes with its own keyboard shortcuts that help to orient users inside of tables.

Instead of trusting (and through research verifying) that a common pattern like data tables would be accessible, their assumption was that they weren’t.

This type of confirmation bias is hard to overcome, especially without experiencing and observing accessibility technologies directly. If it has “accessibility” in it, it must be hard, so it must be difficult for screen reader users, so I have to build a workaround for them.

The misunderstanding also comes in duplicated information or additional bolt-on code that is either inconsequential or, in extreme cases, harmful.

Take the following image code: <img src="…" alt="Image: Lego Space Shuttle">. The addition of “Image:” to the alternative text is completely unnecessary, as screen readers already output this information.

Another example is the misunderstanding of using the tab key to navigate the page. The tab key only goes from interactive element to interactive element. You use other keys to read, for example, body text. I’ve come across more than a few examples where every element on the page had tabindex="0" set, “to allow screen reader users to listen to the content”. No. Don’t do this!

Some of this might come from the notion that you can view accessibility as separate from disabilities. And you really can’t.

Accessibility removes actual barriers for people with disabilities. And you have to learn about the barriers and how they manifest for different disabilities. That will also highlight why the correct answer to accessibility questions often is “it depends”.

There are a few resources that you should be familiar with before jumping in and searching for solutions:

• How People with Disabilities Use the Web from the W3C/WAI is a cornerstone for learning about accessibility. It’s three sub-pages really help to understand the interplay of actual user needs, their abilities, and the barriers they encounter, and tools and techniques they use to overcome the barriers.
  • Stories of Web Users is a collection of personas that you can use to build accessibility into your user stories, but they link to the other sub-pages, which allows you to really understand the needs.
  • Diverse Abilities and Barriers describes different types of disabilities and shows examples of the encountered barriers.
  • Tools and Techniques shows features, assistive technologies, and adaptive strategies that people with disabilities use to overcome or reduce the impact of accessibility barriers.
• Browsing with assistive technology videos from Tetralogical can help to bridge the gap and get a better feeling on how assistive technology actually works.

Of course, the best thing you can do is to observe a wide variety of disabled people and learn how they use everyday websites. As a company, “hire, empower, and promote people with disabilities” (Charles Hall) as a smart way to bring that expertise in-house and have more awareness for everyone. Especially if their workplace has nothing to do with making your actual product accessible.

The last tip is that accessibility conferences often have disabled people show off their everyday assistive technologies. I learned about Augmentative and Alternative Communication (AAC) from Dave Chapple a few years ago at AccessU (which, by the way, has early bird pricing until March 6!). It is a great way to learn about all these different techniques and technologies.

I am personally not a fan of empathy labs or simulating disabilities because they are often counterproductive, as outlined by Sheri Byrne-Haber in her article Simulating Disabilities. Matt May also talks about this in his wonderful talk Design without empathy.

(This blog post was inspired by one of my late-night tweets that got liked and retweeted a fair bit. I thought it would be good to bring that content to the blog.)

Eric Eggert (@yatil) is a Web Accessibility Expert who tries to make the web a better place for everyone. He’s currently Director of Accessibility Services at Knowbility, before that, he worked with the W3C Web Accessibility Initiative to improve documentation of accessibility best practices on the web. Eric shares his knowledge as a speaker, teacher, and on his YouTube channel and blog. Thank you for everything you do for the community, dear Eric!

(Saved here for record keeping, I don’t think there is an archive on the Smashing Magazine site.)

I reviewed the year using this Looking Back at 2021 planner from ink+volt (likely an inaccessible PDF) and it helped me greatly to see what the wins and possible improvements were. The exercise helped me to make sure that I did not only look back at the negativity of the year.

While I have a few specific goals for this year, the big umbrella theme is “The Year of Intent”. I noticed during my review how much of my time I waste unintentionally. Everything I do should have a clear intent, a clear outcome to make sure I use my time productively.

And that does not only mean “productively working” but also “productively relaxing”. I caught myself a number of times in the in-between state between work and free time, where I could not really relax. In the end, I was frustrated that I did not achieve a nebulous goal, but also that I did not properly relax.

In the last week or so, I did experiment with different tools (mostly Craft, Noteplan, Obsidian, and Things) to streamline my (work) tasks. None of the tools is perfect for me, but they each have some features that I like. I also experimented a bit with time blocking, but it can be hard for me to box-in my attention that way.

I’m also struggling with doing proper weekly and daily reviews of the material that accumulates over the week and day… In the morning, I really like to go directly into work because it is when I’m most productive and at the end of my day (which is usually around 7pm), I don’t have a review in me. Maybe I need to start midday reviews?

Anyway, I’m looking forward to being more intentional this year. I started on this blog by implementing webmentions and comments, so feel free to let me know about your theme or goals for the year to test out how that all works.

To be honest, I don’t have an extensive review in me. This has been an extraordinarily tough and stressful year for me. After COVID had held strongly in the winter of 2020, the spring felt to be more normal and ordinary.

That particular calm was only of short duration as we got notice that, due to work from home of our landlord and the additional space requirements, we had to leave our home by March 2022. While the old place had been small for two people, especially when at home around the clock for living and working during a global pandemic, we did not fancy house hunting at all.

That said, by May we had found our new apartment which is closer to nature and also considerably bigger than the old one, allowing more space for the separation of work and nonwork life. We moved in August, and while we made sure that most things were taken care of by contractors, it took considerable time to find the apartment and make the move.

Apart from meeting people that we had to see for the move, we made a conscious attempt to further social distance and isolate as much as possible. This might feel like an abundance of caution, but with two self-employed people and one with considerable experience in lung illnesses (hi!), it still feels the right decision to err on the side of caution. Especially now with Omicron, of course.

That said, the new apartment is great: Two walkable supermarkets, DIY hardware store, and a pharmacy in a 10-minute radius. Thirty-five minutes by foot to the train station. Nature all around us. Woods, fields, views. It is fantastic.

Work obligations and apartment search meant that I was not able to continue with my YouTube videos. I’d really like to continue with them, but I first need to make sure I’m not as exhausted anymore. Health must always have priority. That said, I’m incredibly proud of the 11.500+ viewer figure of my first video. It really feels like I can reach further than with my other channels.

I also did change over my direct support channel to Steady from Patreon. The reason is simple: Steady is a German service, so it works better for business reasons, and it has several interesting features. For example, I might be able in the future to better integrate a membership into this site.

While the video front was relatively quiet, I picked up on blogging in the last quarter with three articles:

1. Buttons vs. Links
2. Fix web accessibility systematically
3. WCAG 3 is not ready yet

I feel very good about that, and I hope to keep the occasional post coming. I have another blog post in draft since July, maybe I can finish it soon.

In contrast to other people, I did not read a lot of books. I can only remember one, to be perfectly honest, and that is Dan Moren’s The Bayern Agenda.

I did consume considerable amounts of other media, some new seasons of last year’s favorites, like the new Ted Lasso (excellent!) and For all Mankind (even excellenter!) seasons.

In summer, I also watched all Marvel movies in release order thanks to Disney+. I think the only one I had seen until then was Iron Man 1 and Spider-Man: Homecoming, and I think both were on a plane. While they were not all great, they were entertainment and I liked the continuing story. I did rate them all on Letterboxd.

In addition, I watched Doctor Who: Flux and Hawkeye (both great!) and over Christmas Around the World in 80 Days with David Tennant, which I liked.

I also built a Space Shuttle and a Telescope! (Link to the tweet with alternative texts.)

All in all, it was a good, but exhausting, year. A lot has changed, and there has been not enough time to really wrap my head around it at this point. Onwards to the next one.

Table of Contents

• What’s the issue with being an early adopter?
• So, what about that “new color contrast algorithm”, then?
• So, should you use APCA?
• What is the way forward?
  • What if…?
• Addendum 2021-12-14
• Update 2023-03-28
• Update 2024-09-16

In the last couple of weeks, more and more people point at the WCAG 3.0 Working Draft and recommend the adoption of aspects from it that suit their needs, despite the draft clearly stating (emphasis theirs):

These are early drafts of guidelines included to serve as initial examples. They are used to illustrate what WCAG 3.0 could look like and to test the process of writing content. These guideline drafts should not be considered as final content of WCAG 3.0. They are included to show how the structure would work.

W3C Working Groups publish drafts to allow the public and W3C members to give feedback. They are explicitly not meant as a recommendation or even as advice. To quote from the W3C process document (emphasis mine):

Working Drafts do not necessarily represent a consensus of the Working Group with respect to their content, and do not imply any endorsement by W3C or its members beyond agreement to work on a general area of technology.
[…]
A Working Draft is suitable for gathering wide review prior to advancing to the next stage of maturity.

What’s the issue with being an early adopter?

In general, web technologies are very good citizens to early adopters like me: They usually come with suitable fallbacks that allow you to use, for example, animations and transitions in 2009 with the fallback of no animation for browsers without support.

With guidelines like WCAG 2.1 and 2.2 (to be released later), the same approach is true. If you use WCAG 2.2 Success Criteria now, the Guidelines are built to be backwards compatible. So you will never break a 2.0 or 2.1 audit by using it.

But WCAG 3 breaks backwards compatibility. This is a conscious move to better adapt the standard to serve different disabilities which WCAG 2 did not sufficiently cover, due to its structure.

That means that WCAG 3 will probably have a different scoring system that does not necessarily overlap with WCAG 2. As far as I know – and my involvement was some time ago – the current plan is to make sure all WCAG 2 conforming pages conform to WCAG 3, too, in some form. They will not in reverse.

So, what about that “new color contrast algorithm”, then?

The visual contrast algorithm that is currently referenced in the WCAG 3 Working Draft, named APCA, is a stark departure from the luminosity contrast algorithm used in WCAG 2.

• WCAG 2 treats front and background color the same, so inverting the color does not change the calculation. This is notably not how color perception works in practice. You can perceive certain colors better or worse, depending on the surrounding color.
• WCAG 2 does not take font-size and weight into account, the APCA does.
• WCAG 2 did not change the required contrast depending on the font, APCA does.

These are all good arguments to change to a new way of measuring contrast, especially as APCA also promises to give designers more color choice. However:

• Any color combination with APCA needs to be checked for both font-size and weight, making requirements documents and design systems more complicated.
• Designers compare the used font to the standard, Helvetica-based, APCA lookup table. This feels like an error-prone step to me, considering that this comparison seems to be done on a visual level. It is not only excluding people with visual disabilities from making their own (accessible) font and color choices, but it also brings a certain level of subjectivity into the rating.
• How the APCA values convert to WCAG 3 ratings is not 100% clear to me. The rating section in the draft (expand the “Rating for Luminance contrast between background and text” for more info) refers to the lookup table values and how you can not meet a number of them and still get a rating. (WCAG 3 aims to not have clear pass/fail criteria, but looser ratings, that give websites the opportunity to be a bit inaccessible and still conform to WCAG to a certain extent.)
• The – admittedly also draft – design and development information for ”Visual contrast of text” has little actually actionable information at this point: How do I choose colors? How do I make sure my design system complies? How do I measure the colors practically? It has some information on display color calibration and the environment, but in my opinion, those should be relevant for determining the contrast using the algorithm.
• The APCA algorithm is changed occasionally (last in March 2021). It’s good that it adapts to new research, but it also means that you might use a color that is not sufficient by a later version.

This reads much more complicated to me, compared to the current way of using colors. It is probably more exact, but it trades off clarity. Designers might get to use orange and white, but there is an additional effort on how complicated it is to evaluate and describe accessible designs.

That trade-off might be totally worth it, but there are many questions that need to be answered between now and then.

So, should you use APCA?

The answer is two-fold:

• For private, non-commercial projects: Sure, go ahead and apply it to the best of your knowledge. There are no restrictions on what you can do, and it might even inform future developments in WCAG.
• For commercial and public projects: You are probably, through law or policy, required to conform to WCAG 2. That means you cannot rely on APCA for compliance (simply because it does not exist in WCAG 2).

WCAG 3 and the consensus process will probably mean that it takes another 3–5 years until WCAG 3 sees any release. And then WCAG 2 will be still enshrined into a lot of laws and policies. After all, WCAG 3 is a huge monolith of a specification, and the structure that the Working Group wants to use is very complex. You can read about it in the WCAG 3 explainer.

In the meantime, WCAG 2 is there for you. Is it perfect? No. Is the luminosity contrast flawed? Pretty sure. But that should encourage us to take the time to make sure that we don’t make similar choices in WCAG 3. As I have outlined previously on this very blog, I don’t think WCAG 3 is necessary the silver bullet that we think it is.

What is the way forward?

I think exploring APCA and how it works with your particular color needs is a good first step, and the Accessibility Guidelines Working Group probably welcomes that feedback. If you use it, be aware that you might not conform to WCAG 2, and you cannot conform to WCAG 3 (as that does not exist yet).

I’m very worried that some designers might think they should or can use the new contrast algorithm, and then accessibility consultants have to push back and clear up those misunderstandings. It takes up a lot of time, while accessibility consultants have their hands full already.

Additionally, it gives accessibility a bad reputation: “You can’t even agree on what colors we should use. Accessibility makes everything more complicated!”. This already is a common sentiment, and speculating what the future might be, based on an early working draft, will not help with it.

What if…?

In an alternate universe, we would have a modular WCAG (similar to what CSS is doing) where every two years or so we package up new success criteria into a new version. It would have allowed different speeds for different SCs, and in this case, we might have a better understanding on what the way forward would be. And if our rating or evaluation guideline would change, the next version of that Success Criterion could address it.

That said, it is so easy to think in these inconsequential hypotheticals. The W3C consensus is that WCAG 2.2 is published some time next year. WCAG 3 follows when it’s done. It’s a long process, and we need to make sure all our i’s are dotted and the t’s are crossed. Let’s just make sure we don’t get ahead of ourselves and create confusion.

Addendum 2021-12-14

Maybe the article did not make that clear: If you use a color that has enough contrast to the algorithm specified in WCAG 2 and the one that is maybe coming in the future, that is great, and it will give your color combination a certain longevity.

Combining both means cutting off obviously hard to read color combinations that are allowed under WCAG 2 while not venturing out of the color space WCAG 2 has inhabited. That means you raise your level of accessibility beyond the minimal requirements of WCAG 2. And that is awesome.

Update 2023-03-28

WCAG 3 is still not ready. In fact, there haven’t been any meaningful updates to the draft since this article was initially published. The proposed charter for the WCAG WG has a completion date of Q2/2026, which is probably unrealistic. (Minor WCAG 2 updates took between 5 and 10 years, but now they want to create an entirely new standard with new testing requirements and documentation in three years?)

Update 2024-09-16

Rachael Bradley Montgomery, Accessibility Guidelines Working Group Co-Chair, asked me to update this article in a comment on LinkedIn: AGWG are updating the draft now every 6 months or so. A few points in the article need updating: 1. We are currently testing our velocity and do not expect to provide a final schedule until next year when we have a better estimate. 2. APCA is not in the current draft. We hope to put out our next update this fall and appreciate everyone who provides feedback, while recognizing that WCAG 3 is a work in progress!

• Date: November 30, 2021
• Time: 8–9pm CEST (Berlin)/1–2pm Central (Austin)
• Register for the webinar! It’s free!

Please send questions in via Twitter with the Hashtag #A11yOfficeHour.

This event supports Knowbility’s current donation drive. So please support Knowbility and its mission by making a donation.

Today starts W3C’s TPAC Conference. It’s where all W3C groups have an opportunity to meet and make sure that they work to bring the web forward. There is usually a lot of accessibility going on, but it is far from embedded across the organization. That has structural reasons (W3C’s Web Accessibility Initiative — WAI — is a dedicated section inside W3C) and while WAI checks all specifications for accessibility, most are not developed with accessibility in mind from the beginning.

And even the specifications that are developed for accessibility, have significant adoption problems. The only accessibility standard that got real traction is the Web Content Accessibility Guidelines (WCAG) 2. There is also ATAG 2.0, the standard for authoring tools, which is basically everything that creates web content (blog engines, social media sites, video sharing), but few tools adapt parts from it, let alone everything.

UAAG 2.0, the standard with the goal to make browsers and other user agents accessible, did not even get published as a standard, but as a working group note. There was not enough consensus to make it a requirement for browsers.

Another standard that W3C/WAI develops is ARIA (Accessible Rich Internet Applications)[^ This is a link to the ARIA 1.2 Candidate Recommendation Snapshot. I think that means it is technically a draft, but is close to being a recommendation. Unfortunately, W3C changed the naming of the documents, and I find the changes hard to understand.], which provides roles, states, and properties to make rich user interfaces accessible. It is a whole different set of semantics that you can add on top of HTML to make your website more accessible. It can also be used in other technologies, like ePub or PDF.

While developers would have used ARIA initially to adapt their HTML to the API for screen readers in complex situations, these days ARIA is almost a must-have even on the simplest website. If you have two navigation areas on the page, let’s say a visually horizontal main navigation and a vertical sub-navigation, it’s common to give them names. There is no mechanism to do that in HTML, so you have to go back to ARIA for that.

Accessibility got complicated and unpredictable

To build an accessible product, you need to know how all of these technologies interact and how you can combine them to create an accessible experience. You have to know what an accessible name is and if the aria-label attribute overwrites the aria-labelledby attribute. (It does not.)[^ Thanks to Mitchell Evan for pointing out that I initially had mixed up the priority between aria-label and aria-labelledby — accidentally proving my point.]

W3C provides a host of additional specifications for that, like the ARIA Authoring Practices[^ Linking to the editor’s draft, because that is better aligned with ARIA 1.2.], which demonstrates how ARIA works. But its examples do not reflect HTML best practices, as it is technologically neutral.[^ See, for example, this example of making a span element a link. I understand why this example is here, I also understand how people see this and come to wrong conclusions.] There is also HTML Accessibility API Mappings, which explains the relationship of how HTML maps to accessibility APIs, especially when using ARIA. And the ARIA in HTML specification, that gives advice on how to use ARIA in the first place when using HTML.

On top, you need to understand the capabilities of assistive technology and how it can actually use some of these technologies. Due to the vast market of assistive technologies, there is always uncertainty. And that HTML elements, like <input type="date">, which are standardized for over a decade now, lack accessibility support in modern browsers does not make it easy for developers.

“Don’t use ARIA unless you have to” is a common phrase uttered by accessibility experts, but how are ordinary developers supposed to know when they have to? The education around accessibility is abysmal and instead of making sure that it is really clear what to use in what situations, we just leave it to designers and developers to make these critical decisions.

WCAG 3 will not fix that issue

A lot of people have high hopes for WCAG 3 (the then likely renamed W3C Accessibility Guidelines[^ W3C Accessibility Guidelines: WCAG.]). But accessibility testing is the least of our problems. Nothing will magically let developers understand how to achieve a certain outcome[^ WCAG 3’s version of a success criterion] when WCAG 3 gets to recommendation status. It won’t make any of the interplay of the technologies easier. (And the jury is out if it will actually improve accessibility testing.)

We need a combined effort

There already is some wiggle room in accessibility: What alternative text is correct in what situation? Is something a button or a link? It is good that we can make decisions depending on the context, as the web is such a complex medium.

But if something is in ARIA, it should have the defined result in the DOM and AOM[^ That’s the Accessibility Object Model, a parallel Accessibility-focused version of the Document Object Model (DOM).] and thus a predictable outcome in assistive technologies.

For example, if you currently specify aria-haspopup="dialog", most screen readers will announce that a menu will pop up. That's not super useful.

This lack of predictability and interoperability hurts users. Developers cannot rely on the technology to work, which takes up resources that could be better spent elsewhere.

Initially, when we talked about ARIA, the plan was that most aspects of it would be converted into native HTML quickly. Combo boxes, dialogs, tab panels[^ Oh, looks like Open UI will have that covered soon, Dave Rupert is looking into native tab panels.]. The promised land of a world with natively accessible features right out of the box, it did not come to pass.

Instead, ARIA is now a meta language that sits between technologies, defining an accessibility vocabulary for them. This led to the interesting development that ARIA takes on features of HTML instead of the other way around. ARIA now even has a paragraph role.

Who can blame developers when they skip over searching HTML and go directly to ARIA — it has accessible in the name, after all. But ARIA is a much less forgiving and can be much more damaging than a bad HTML element somewhere usually is. And it also is more complicated. Some roles must be inside other roles. Using certain roles demands implementing predictable keyboard navigation (and no, you do not get that for free).

What to do?

I think we need to make sure that accessibility implementation is predictable, easy to understand and error tolerant. With the heavy reliance on ARIA, and barely any movement of getting accessibility into the core technologies[^ I’m counting on you, Open UI!], we made accessibility hard to understand for most developers and added more and more variables. And that is all before actual support for assistive technologies.

To make it easier to use, we have to bring accessibility back and modernize existing basic standards. It will simplify documentation, improve reliability, make errors easier to detect. And it will help to make accessibility easier to teach.

And browsers must do their fair share of it, too. Why is there no console warning, when a form field is missing a label? Why can I pollute my HTML with nonsensical ARIA attributes without the browser even raising an eyebrow? Every role="link" should yield a “Didn’t you want to use an a element instead?” message.

If we want the web to be “for everyone”, its tools must be for everyone, too. And that begins with accessible core ingredients like HTML.

Did you like this article? Support my independent work with just €5/month.

Update 2021-10-20: Added footnote regarding Open UI tab panel explorations.
Update: 2021-10-23: Corrected aria-labelledby overwriting aria-label.

What are links?

Links are interactive elements that usually link to another document, for example: Click this link to go to Knowbility’s website. There is some additional functionality, like the ability to point to different frames in a “frame set” (yup, you can still do that!) or forcing a download of a file.

In essence, the link changes what the URL in the browser points to and then displays that website or file. If the browser can’t display the file, it gets downloaded.

Links give you also several additional options in the right click menu: Opening the target page in a new window or tab, download the linked page, copy the link. When you hover over the link with the mouse, you can also see the destination of the link in the status bar.

In addition, some links only bring you to a different section of the same page, which is useful, for example navigating footnotes[^ Footnotes are these small additional information section at the bottom of the page. Pretty much like this one. Actually, exactly like this one.]!

What are buttons?

Buttons perform an action. When they were introduced as a variant of the <input> element, their sole purpose was to submit forms. They are still pretty great for that. Later, HTML introduced the <button> element, which allowed more versatility of buttons outside of forms.

While you can get redirected after a form submission, back in the day, the website would often just stay on the same URL and display a success message. With the <button> element, buttons can now be used for functionality all over the site that does not lead a user somewhere else.

Have a calculator on the site? A great use for buttons. Expand a navigation? Use a button. Show/hide something? A button can do that. Basically, a button would always be used either in a form or with JavaScript. Without JavaScript, the usefulness of buttons is severely limited.

What are the differences between links and buttons?

First, they have two different roles, so assistive technologies announce them differently. Links are (shockingly accurately) announced as “links”, while buttons are announced as (you might have guessed it by now) “buttons”.

Having these different roles means there are different user expectations. Not only that links go somewhere and buttons do something, but also their interactivity:

• Links can be activated by pressing the return key only.
• Buttons can be activated by pressing return or space.
• Screen readers have a function to present a list of links to their users. Buttons cannot be as easily reached.
• Buttons use the normal mouse pointer arrow, while links trigger the use of the pointing hand mouse pointer.

As a developer, it is important to embrace that difference and know about it, as you can much easier meet user expectations that way.

What about styling links and buttons?

The same principles apply to links and buttons for styling. Users generally will have the expectation that…

• Underlined text goes somewhere.
• Text in a pill or rounded rectangle shape does something.

That said, on the web there has not been much of a separation of the two than on desktop operating systems. The power of CSS to make every element look any way you like blurred the lines here.

Call-to-action links (CTAs) often have a button-like shape. At the same time, we might have lists of links that look nothing like those in the body of our texts for navigation or in a tag cloud.

This is usually not a problem because context is a thing that can help users to identify what’s going on. In a teaser that has a pill-shaped link that reads “Read the full story”, people will not confuse it with a button to do something on the page.

Imagine a button that is styled to look like a text link, but has a pencil icon and reads “edit”. There’s a good chance users won’t be surprised when they trigger an inline editing mode, which does not lead them to another page to do the edits.

Conclusion

Buttons and links are functionally different, but their styling can be similar. Use the proper tool for the job and remember that links go somewhere while buttons do something.

If you style them similarly, make sure that the functionality is clear from the context. You can add other clues to differentiate:

• Make call-to-action links a more pill like appearance, if your action buttons are rounded rectangles; or the other way around.
• Use iconography that supports the use. An arrow to the right on a call-to-action link is a great indicator to say, “this goes somewhere!” (To the left on right-to-left languages.)
• Use meaningful descriptions as link or button text. “Download document”, “Submit form”, “Save progress”, “Read article” are all probably as or even more instructive to direct user’s expectations compared to the actual shape of the link or button.

You should care about the difference

With both elements in a gray area, it might not make a huge difference on what to use. And that might be true for the occasional link that should be a button, or for the individual button that just redirects you somewhere. But if you depend on the role of the element every day, like screen reader or speech input users do, the reliability of these very common elements is key.

If you had a keyboard and your “e” key would only work 90% of the time, it would be infuriating. Reliability and trust in user interfaces is important to allow users to navigate content and application with ease. If you use the right elements, you support users.

That said, because of the complicated and diverse history of the web, in some instances there is no one true way to code or design something. Designs, development environments, approaches, and preferences can differ. Where I would have used a button and styled it that way, another user might have used a link. And that is totally OK.

Thanks to Hidde, Erik, and Nic, who reminded me about some things I forgot to mention in the first draft. Also, to everyone who shared their opinion and experience on Twitter. This is how we learn. And last, but not least, let me refer to Marcy Sutton’s talk “The Links vs. Buttons Showdown”, in which she comes to similar conclusions as I do. Carolyn reminded me of it via Twitter.

Podcasts

Unfortunately no podcasts listed have transcripts. The inaccessibility of podcasts is a really big problem.

Tech

• Relay FM is a podcast network that hosts some of my favorite tech-related podcasts: Upgrade, Connected, Automators and Mac Power Users.

• Let me single out Relay FM show 20 Macs for 2020 here, which looked back at the most notable Macs until now. There is a series of articles and YouTube videos that complement the podcast (or vice-versa?).

• Nested Folders – A productivity podcast.

• Accidental Tech Podcast (ATP)

• The Talk Show

Non-Tech

• The Incomparable is a popular culture network. I love their TV series recaps, the main show which has panels about a lot of topics and Total Party Kill, the Dungeons and Dragons podcast (start with the Dragonforge & Associates campaign or the ongoing Dog and Pony Show series). They also do an incredibly funny Gameshow. If you consume popular culture, you’ll find something that you like there.

• Several Doctor Who podcasts, including Verity, Radio Free Skaro, Reality Bomb and Five Years Rapid.

• Writing & Breathing is an interview show where writer Antony Johnston interviews other writers about their processes. It’s been a great inspiration to write more, and while that has not resulted in more blog posts, the scripts for my YouTube videos have been directly inspired by it.

TV & Streaming

All TV series have captions and many also have Audio Descriptions. The accessibility options on Apple+ are especially plentiful, captions & subtitles in many languages and audio description in about 10 languages.

• Doctor Who helped me in two ways: First, the new series that ran from January to March was really good. Second, the announcement of a “festive special” at the end of the year gave me something to look forward to. In addition, the animated miniseries DALEKS! was shown on Youtube.

• The Mandalorian on Disney+ had two very good seasons released this year (because Europe got Disney+ a few months late it was all released last year for us). In addition, Disney Gallery is the behind the scenes series that covers the fascinating technology used filming it.

  Dan Moren published a fantastic recap podcast on The Incomparablecalled A Complicated Profession.

  The Mandalorian also let me to start watching the animated Clone Wars series.

• Ted Lasso on Apple TV+ is a comedy and starts with the classical fish out of water tropes, but quickly allows peeks behind the curtains and then turns all the preconceived notions on their heads. It’s just 10 short 30 minute episodes, and I can’t wait for season two!

• For All Mankind is an alternative history that explores what would have happened if the USSR had won the race to the moon. Also Apple TV+.

• Mythic Quest: Raven’s Banquet is a comedy about the work in a game development studio and I enjoyed the humor in it quite a lot. They also shot a socially distanced special which is super heartwarming.

• Killing Eve is a fascinating spy thriller series about a serial killer and an intelligence officer. When the two women’s paths cross, they discover what they have in common. It’s quite violent at times, but an incredible interesting story. (Unfortunately, the version of Killing Eve that I watched through the Apple TV Starz Channel had terrible captions.)

The year took off quite ordinary. My workshop at a11y.club in Berlin the previous November went well, and I looked into how to do more of these seminars with people. Suffice to say that planning for in-person events was not the most useful thing at the time. Oh, how little did we anticipate.

In February, the signs of a worldwide crisis deepened, and while it was clear that these would be extraordinary times it felt save enough to do the yearly trip to CSUN in California in early March. By then many companies had withdrawn their travel but apart from the Conference itself, which was happening on a much smaller scale, the risk seemed low as long as we washed our hands and kept our distance.[^ I very much understand now that the risk level was probably higher than we could assess at the time. It is easy to second guess the decision in hindsight.]

That’s exactly what we did. And as the pre-conference meetings fell flat, I took a day off, and we took the opportunity to visit Disneyland. The park was relatively empty (during a weekday) and we had a good time stying in our bubble as much as possible and hand-sanitizing a lot.

Once CSUN was over, we traveled to the Anza Borrego Desert where we had rented a house for the week and wanted to continue to San Diego afterwards. During our hiking trip, California mostly locked down. As getting outdoor and away from people are one of the main reasons doing these trips to a mostly remote place, it did not impact us too much.

As it became clear that walking leisurely along the Beach in San Diego would not happen, we extended our stay in the desert. Ultimately, our flight back was cancelled, and we got rerouted through Boston and to Amsterdam, taking the train for the last leg of the Journey. I have never seen airports so empty. In Boston, our flight was the only non-cancelled flight on the schedule boards.

It was super lucky that we could have a trip like that. The timing worked out and we stayed healthy. That said, since arriving at home and with the growing consensus about masks and how the virus spreads, we isolated completely for the rest of the year, only leaving the house for groceries every 10 days or so.

March was also the last time I worked with W3C. Together with Knowbility I decided that it would be good to focus on Knowbility projects.

The next couple of months were a real rollercoaster, especially losing Christopher was a kick in the gut I have not really recovered from. I miss him dearly.

In May, Knowbility shifted their AccessU conference online, and it was a resounding success. At the same time, I was asked to lead the small-but-mighty tech team.

Saying that I was unsure if I could do it would be an understatement. But I was more than happy to try it and the response from the team and the work we did since then has assured me that I can guide them even as I am figuring all of it out myself.

After May, I did not do a lot of public speaking. With the nonexistent travel cost, I hope that people, that don’t have the resources, get more opportunities. I did a half-day online workshop for Knowbility about Inclusive Design in September.

In the fall, I started a — in my opinion — successful venture into YouTube video production. I’m delighted with the six videos I have created, with a combined 3.800 or so views, and with the response that I got so far from the community. The videos are embedded on this website (in a privacy-respecting way). They have all closed captions and transcripts. It’s nice to have a project that is creative and helps me to reach a wider audience than through conference talks. I hope to further improve the videos and publish more of them.

I also signed up for micro.blog in an attempt to spend less time on Twitter. You can find my microblog here: micro.yatil.net.

I have collected my TV/streaming and podcast highlights in a separate post. Those were wonderful distractions.

For 2021, I hope that everyone stays virus-free and that the vaccinations are successful and quick. I’ll hunker down as long as it takes — and you should do the same.

I use my Raspberry Pi Zero mainly for Homebridge, a way to use non-Homekit devices from my iPhone, iPad and Mac. Homebridge is based on Node.js but as the Pi is based on ARMv6, there is no official version of Node since version 10.x. Newer plugins demand later versions of Node, so I had to find a way to install it.

Fortunately it is pretty straight forward to install it from an unofficial repository. I followed the instructions on this web page, but I replaced the source of the compiled build.

1. Connect to your Raspberry Pi using SSH.

2. Find the latest build you want to install at unofficial-builds.nodejs.org/download/release/

   When I tried it, the current version was v15.1.0. In the current directory find the version for ARMv6, which is the file that ends with -armv6l.tar.gz.

   Make sure to use the correct version number in the commands below.

3. On the command line on the Raspberry Pi download that file using the following command:

   curl -o node-v15.1.0-linux-armv6l.tar.gz https://nodejs.org/dist/v15.1.0/node-v15.1.0-linux-armv6.tar.gz

4. Extract the files by using the tar command:

   tar -xzf node-v15.1.0-linux-armv6l.tar.gz

5. Move the files over from the extracted directory:

   sudo cp -r node-v15.1.0-linux-armv6l/* /usr/local/

6. In case you are greeted with the following error message:

   cp: cannot create regular file '/usr/local/bin/node': Text file bus

   You need to remove the node file first:

   sudo rm /usr/local/bin/node

7. Restart the Pi or Homebridge to make the changes stick.

In the end, the whole process was not too bad and felt actually pretty straight forward once I found the unofficial builds.

They are unofficial and unsupported for a reason, so stuff might break in the future, but for now, everything looks good so far.

The subtitle is “The Big Picture” as it continues my quest to connect all the dots between accessibility, design, inclusion, and society.

Find a full description of the seminar on Knowbility’s website.

Initially, I wanted to do a re-run of my Connecting the Accessibility Dots workshop that I did for Accessibility Club Summit in Berlin in-person in fall of 2019. But it did not sit right for me. Back then we have not been in a global pandemic, and it was before the recent Black Lives Matter protests.

Not talking about how these circumstances must change our view of the world and our approach to how we create things would be out of touch. Hence, I want to take a more holistic look onto the web industry and technology as a whole for this seminar.

Inclusive Design embraces diverse viewpoints. They are used to creating products, services, and relationships that are better for all people. It is a human-centric design philosophy.

To promote, Knowbility interviewed me about my motivation:

I was raised with a strong sense of equity for everyone, and I saw how society can benefit some groups and let others down. I think my first eureka moment growing up was when a friend of mine, who was using a wheelchair, had to go to a “special” school here in Germany because other schools were inaccessible. He had exactly one option to participate in the education system, while I always had multiple options. […]

[W]hat keeps me going[?] My love for the internet as a medium, really. It is something that we as a society are so accustomed now, everyone uses it. And I just want to make sure that everyone can still use it forever, regardless of disability or age. And deep down, I, selfishly, don’t want to lose access. So, I work to keep it.

Read the full interview on Knowbility’s website.

If you find this interesting, please sign up for my seminar. It will be fun, honest, conversational and, hopefully, insightful. A standard ticket is $149, with educators and students paying only $99. Scholarships are available if you cannot afford it.

All proceeds help Knowbility’s mission for equal access to technology for people with disabilities.

Here’s what attendees of my past workshops had to say:

Sound

Zoom compresses the sound in meetings to send it to attendees more, so investing into sound gear should not be the highest priority. That said, clear, intelligible sound is much more important than everything else. If you’re hard to understand or if there’s a constant noise from your line, attendees might not be able to follow you.

Always use headphones. I have seen guidance that headphones look amateurish, but that is not true from my point of view. You want to understand audience questions or your moderator. That’s much more reliable when they are in or on your ears.

Microphones play a secondary role. You can use many laptops’ built-in microphones for your presentation. (But try it out beforehand!) It is very important to bring the microphone as close to your mouth as possible. You can do that with a headset or a table/podcasting microphone. But the wired headset included with your mobile should also work well.

I use a wired connection to my Mac to do my talks, but Bluetooth headsets or AirPods might work for your use case, too. Keep in mind that there is a brief delay with wireless options on top of the delay from the internet connection.

If you have a good microphone, Zoom gives you the option to send out non-processed audio in the settings.

Video

On videos I strongly prefer my real environment from those virtual backgrounds that are so en vogue these days. That said, I have my office carved out to support the “talk to the computer” use case. You might not be so lucky. If there is no suitable place to hold the presentation, virtual backgrounds are an excellent alternative. (And that also includes socio-economic reasons for not showing one’s living conditions.)

When using virtual backgrounds, I have seen fewer artifacts with photos that contain a lot of details. Backgrounds with solid colors have been more problematic. A picture of a forest might be better than your corporate colors displayed behind you. Make sure to not have “virtual background dismemberment” happen during your talk. If you wave around your hands while talking, your arms might look cut off with a virtual background. The edges of the top of a high-back chair can glitch in and out the background even if you only move a bit. Finally, turning your head can lead to your nose looking cut off.

Lighting is important, especially as laptops have mediocre cameras. (iPads and mobile phones are much better in that regard, but usually not suitable for many to do presentations on.) Make sure you have a bright light source in front of you. I have a daylight ceiling lamp that makes sure I have good lighting. Have as little light from behind you and from the sides. Light from behind you makes the camera overcorrect, so your face will be in the dark. Light from the side can lead to one half of your face almost dark while the other half is brightly lit. (And you don’t want to look like Two-Face, right?)

Try to look at the camera as much as possible. If your computer displays a (green) light where the camera is, try to look at it as often as possible to have “eye-contact” with your audience. It helps if your slides/notes are underneath the camera. Try to avoid having notes above the camera.[^ I think the use of teleprompters have trained us that someone looking down under the camera is more acceptable than someone looking over it. But then TV teleprompters are much further away from the speaker, so it's less noticeable that they are not looking into the camera.]

Position your head in the center of the frame, if possible with your eyes about a third from the top.

Internet Connection

Issues can arise from your internet connection not being up to the task. If you’re doing a talk during the day, your neighbors will also use the internet heavily, putting stress on the connection. There’s little you can do. I have used tethering to my iPhone when I had a complete landline blackout[^ …and I also presented from my iPhone once, but that is a story for another time. I’ll just say, having a PDF version of your slides on your phone might save your talk.].

Switch all heavy data users off. That includes Dropbox, Box, iCloud and those torrents that might run in the background. On Mac and Windows, you can use the app TripMode to only allow your presentation software and Zoom to connect to the internet (And Slack, if that is used to communicate).

If you have the possibility to connect to wired networking (“ethernet”), do so to cut out a potential issue. Yet, I do not have ethernet here and had no particular problems with wifi.

Computer Performance

If you want to be sure that everything is going without a hitch, I recommend closing all apps you don’t need for the presentation. You might even want to do a fresh reboot to make extra sure it all works.

Presentation/Display Setup

While I’m certain your setup different, here’s what I do: I like to have one display dedicated to my slide deck that I share with to Zoom. That way if I need a browser window to show something, I can drag the window over there. You can share only a particular window in Zoom, which is useful if you don’t have an extra display and don’t want the attendees to see other information.

I recommend using a presentation remote (“clicker”) like in an offline presentation, even if you only hit the right arrow key to advance the slides. It prevents you from pressing a different button by accident or losing your place on the keyboard.

When you need to share the sound from your computer, do not forget to check the “Share computer sound” checkbox in Zoom. If you play videos, the “Optimize Screen Share for Video Clip” option should give you a better refresh rate. It should make videos less choppy for the audience. Both options should appear on the bottom of the “Share Screen” menu that shows up when you click on the share screen button.

Notifications

Make sure your computer, phone, watch are in Do Not Disturb mode during the presentation.

I met Christopher in person for the first time when I spoke at AccessU Online in 2015. He was organizing the conference and his warm welcome made me immediately comfortable.

There I was, embraced by Christopher’s smile and his generosity to invite me to his event. Events, that I admired from afar and I only had a tiny bit of hope to be ever involved in. It was a busy day, so we did not get to speak a lot but his care and his passion really came through.

I was stoked when I learned that he was joining the team at Knowbility just a few years later. While his expertise and his knowledge of all things good HTML/CSS/JS were much appreciated and he helped with organizing our online events, his attitude and kindness had an even greater impact.

I cannot recall a meeting where he was not smiling, where he didn’t have a funny and/or insightful comment. He rarely took compliments for himself without highlighting the accomplishments of others in the team. He was just such a good person.

Christopher has touched so many of us with his kindness and positivity. The world needs more Christophers, not fewer. But here we are.

For an impression of how important Christopher was for all of us in the web community, read through the condolences on Twitter. Dave Rupertand Chris Coyer have also written about Christopher.

My thoughts are with his partner Ari and their families. 💔

When I worked on this site the last time — apart from content updates, of course — I moved from Jekyll to Kirby. Now I have decided to move on from Kirby to Eleventy, a JavaScript-based static site generator.

There's no particular reason behind this change. I ran into some issues with the two languages on this site, and broke my Kirby installation briefly. And while it was quick to roll back, the overhead of a whole PHP application with Vue-powered backend felt wrong for a site that essentially publishes simple formatted hypertext.

So here we are. A simple theme, based on the eleventy-base-blog and a new coat of CSS paint is all I needed to release it. And for the first time I dabbled in using a variable font: Working with Recursive was a lot of fun, and it turned out to be very versatile.

I plan to write about the extremely simple CSS file and how I used CSS Custom Properties to make my life easier.

Expect that some posts are broken, converting between different Content Management Systems is always a challenge. If you find something, let me know.

Update October 2021: I changed back to Kirby.

It is an updated talk from the one I gave several times before but it is always nice to document new and inventive atrocities.

When: October 2, 2019, 11am ET
Where: Online, Register here

In this new workshop I want to help people wo have an understanding of specific parts of accessibility to get a better understanding on where this fits in the general framework of designing, writing, and developing accessible websites. The learning outcome should be a holistic approach to accessibility that leads participants to anticipate accessibility-related issues earlier.

We look at the requirements for accessibility, the needs of people with disabilities, and how assistive technologies work. We’ll answer the important questions about accessibility: Why is it important? What are the important concepts? How do people with disabilities actually use the web? How can we create accessible websites without consulting WCAG at every step? When, and how, can we make sure that we don’t step into the same traps all the time again and again?

In the second half of the workshop I’ll then answer the specific questions of the audience (provided in advance), applying the approaches learned in the morning to practical use.

When: November 17, 2019 (with Accessibility Club Summit Barcamp on Nov 16 and after beyondTellerrand, Nov 14 & 15)
Where: To be determined, Berlin

Buy tickets for the workshop at accessibility-club.org!

Unfortunately there often is no link to the Overcast URL directly on the page despite Overcast having decent web integration[^ Which is one reason I switched back to Overcast twice after extended stints of trying out Castro where I prefer how podcast playlists are managed.]. Adding a podcast to Overcast in this case means copying the title of the podcast, open the web interface or the app, searching for the podcast, searching for the episode to sample. and adding this episode.

It’s not the end of the world, but it introduces some friction that seemed unnecessary to me.

Overcast accesses the iTunes Apple Podcast Directory and its podcast URLs take the same ID as is present in that directory. Due to the nature of Apple Podcasts, every podcast has a link to their entry on the page.

JavaScript to the rescue!

I have created the following JavaScript[^ Not really rocket science.] which searches for podcast links (two variations). If one is found, it extracts the ID using a regular expression, adds it to the Overcast URL and opens the URL in the current window/tab.

const regex = /podcast\/id([0-9]*)/i;
var itunes = document.querySelector('a[href^="https://itunes.apple.com/"][href*="/podcast/"],a[href^="https://podcasts.apple.com/"]');
if (itunes) {
  var itunesid = regex.exec(itunes.getAttribute('href'));
  var overcasturl = 'https://overcast.fm/itunes' + itunesid[1];
  window.location.href = overcasturl;
} else {
  alert('No Apple Podcasts link found. 😭');
}

I then used Peter Coles’ Bookmarklet Creator to generate a bookmarklet.

To install the bookmarklet, drag the following link to your bookmarks/favorites bar:

Open in Overcast

While searching for the episode and to add is still needed, I hope to try out to more diverse podcasts this way.

His[^ Note that this is using Andy’s use case as an example. He immediately added a note to his article when I made him aware of the accessibility implications. I wanted to write this up as a lesson in how the web changes and how different aspects of the web can work together. After all the web is constantly evolving and we’re all learning all the time.] goal was to provide text effects by layering different styles of the same font on top of each other. Designers use this technique to extend a base font style with other flourishes of the same font. The final code he came up with is this HTML, using the notranslate class to prevent translation of the heading[^ Usually I would oppose to remove the ability for users to translate content to their language. In some circumstances, like proper names, this can be OK.]:

<h1 class="type-family-jakob notranslate" data-heading="France-Norvège">
  France-Norvège
</h1>

The CSS looks like this:

[class*="type-family"] { position: relative; }

[class*="type-family"]:before, [class*="type-family"]:after {
  content: attr(data-heading);
  position: absolute;
  z-index: 1;
  overflow: hidden;
  left: 0;
  top: 0;
  font-size: inherit;
  font-weight: normal;
}

Until a couple of years ago, the browsers did not treat generated content as “real” content. They did not expose it to assistive technologies like screen readers. That created an issue, for example when web developers used CSS to specify the file format of a document:

<a href="link/to/an/interesting.pdf">
  Get the Report
</a>

a[href$="pdf"]:after { content: " (PDF)"; }

For visual users, the link text “Get the Report (PDF)” would have been clear. But “(PDF)” was not conveyed to screen readers and other assistive technologies and thus not their users. Most developers don’t intend that behavior, so browsers started to treat generated content as actual content.

Back to Andy’s example. The “accessible name” (the label that assistive technology uses) of his heading rank 1 would include the :before and the :after version of the contentand the content of the <h1> itself. The browser “sees”:

<h1 class="type-family-jakob notranslate">
  France-Norvège France-Norvège France-Norvège
</h1>

There is an ARIA attribute that we can use to overwrite[^ A note, because I see that in accessibility assessments all the time: If you use aria-label, the content of your element is not revealed to assistive technologies. Writing <a href="…" aria-label="opens in a new window">Visit our partner site</a> will result in a link that only says “opens in a new window”. Just don’t use it that way. OK?] the content of the <h1>: aria-label. So we could augment Andy’s code like this to avoid tripling the heading:

<h1 class="type-family-jakob notranslate"
    data-heading="France-Norvège"
    aria-label="France-Norvège">
      France-Norvège
</h1>

This would work, but having two attributes repeating the content of the heading feels wrong. As attr() can use any attribute, not only data-attributes[^ Indeed, attr() was invented long before data- attributes were a thing.], we can use it with the aria-label and remove data-heading:

<h1 class="type-family-jakob notranslate"
    aria-label="France-Norvège">
      France-Norvège
</h1>

[class*="type-family"]:before, [class*="type-family"]:after {
  content: attr(aria-label);
  …
}

This is where this story could end. And indeed this is where this story would have ended a couple of weeks ago. Yet, thanks to accessibility advocates, aria-label is now actually one of the attributes that istranslated when using Google Translate through Google Chrome – but not in other browsers. If that is enough to remove the notranslate class from the heading depends on your circumstances. As the short clip of this example codepen shows, the aria-label attribute translates nicely:

` or `

` semantics, so they are usually not announced. In fact, even such useful elements as `

` and `

` usually have no recognition at all in browsers[^Which is a shame, they are so useful!]. ## So we need standards for screen reader output! Yes, and no. Users of screen readers are very diverse. Many screen reader users can see the screen. Some know every bit of the screen reader’s settings, other users struggle with the essential functions. In the end, a screen reader is a highly personalized piece of assistive technology. In principle, I’d personally prefer the behavior to be a setting in the screen reader (VoiceOver) itself, rather than Safari deciding what to do. On the other hand that has also ramifications: How would the browser communicate that it deems a list is used for “layout”? We generally don’t want assistive technologies to access the HTML directly, because this lead to issues in the past. ## Next steps? Of course, we can yell at browsers and assistive technologies for making our lives more complicated, but the reality is that we are living in a complex world and there is not a black and white answer (yet!) on how to tackle issues like this. > We really need an open conversation on what CSS is allowed to overwrite semantics. Apart from display:none/visibility:hidden, I personally think no CSS should alter the semantics of the page. The above paragraph was my hot-take two days ago. I’m not sure if it holds up as much as I would want it to do. I think we need to define the expected or preferred behavior of user agents somehow but to flat-out forbid interpretation might be to the decrement of the users. We have come so far to agree that [websites don’t need to look the same in every browser](http://dowebsitesneedtolookexactlythesameineverybrowser.com) mostly due to bugs in their rendering engines or preferences of the user. I think the same is true for screen readers and other assistive technology: **Websites don’t need to sound the same in every screen reader.** The issue with “listitis”[^ Using lists to structure every little part of the content.] stems from HTML not having a lot of ways to structure content differently. Do we really need `

See the Pen Line-On-Sides Headers with Flexbox and minimal lines by Eric Eggert (@yatil) on CodePen.

See the Pen Line-On-Sides Headers with Flexbox and border images by Eric Eggert (@yatil) on CodePen.