This is a general guide designed to help you understand, build, and distribute various formats of web feeds, even if you've never touched them before. We're not going to run through all the uses and details of syndication feeds, because they've been covered ad nauseam elsewhere. Instead, this article is designed to act as a reference which focuses on the principles of various feed formats so that people can subscribe to your content.

Consider this your article as a point of entry, or reference cheat-sheet.

RSS

RSS has the best support out of any feed format but is also the oldest and has some design issues that can make it unideal. RSS files should be served with the MIME type application/rss+xml. For an example of a full RSS feed, you can view the feed for The Index: https://piccalil.li/the-index/feed.xml

Boilerplate

Like all of the formats this article will be discussing, RSS is just text. In this case, structured XML. RSS wraps everything in an <rss> tag with a version number, and then a single <channel> tag, which all of our RSS content will be held within.

<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
  <channel>
  </channel>
</rss>

Metadata

Before listing our articles, we need to describe the feed itself. We are required to have at least a title, link, and description, like so:

<title>Name of our feed</title>
<link>https://example.com</link>
<description>A short description of the feed.</description>

However, there are also many additional optional values we can include: language, copyright, managingEditor, webMaster, pubDate, lastBuildDate, category, generator, docs, cloud, ttl, image, rating, textInput, skipHours, skipDays.

Dates in RSS conform to RFC-822. This means they look like this: Tue, 11 Jun 2024 15:00:00 GMT. Though RFC-822 does permit two-digit years, four digits are widely preferred.

Items

Items are the individual entries in your RSS feed, whether they be posts or something else. There are two schools of thought for what content should be included here. One follows the idea that feeds should contain the entire content, unabridged. Others think that feeds should only contain a summary of the content and that it should be read on the site. The preference differs by user, but there is no downside to supplying both if you wish.

The items are the meat of the feed. You loop through your posts and output an item for each one. In RSS, each post is an <item>. All elements in an item are optional, but you must have at least a title or description.

<item>
  <title>A quick and easy guide to Markdown</title>
  <link>https://piccalil.li/blog/markdown-guide/</link>
  <pubDate>Tue, 11 Jun 2024 15:00:00 GMT</pubDate>
  <description>This is the summary of the post...</description>
</item>

As a word on etiquette, don't publish items with future dates. Most feed readers will just omit them, but some will display them at the top, which is attention-grabbing. Many users consider this bad manners and will probably unsubscribe.

Atom

Like RSS, Atom is XML-based, but is a little bit stricter and more finely specced than RSS, which makes it slightly less forgiving to author, but much nicer to parse. Atom files should be served with the MIME type application/atom+xml.

You can see a full example of an Atom feed here.

Boilerplate

Atom uses a root <feed> element and requires an XML namespace (xmlns).

<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
</feed>

Metadata

You need an id, title, and an updated timestamp. The homepage URL is often used for the id value. author is also required, unless every single entry has an author value.

Atom dates are written in accordance with RFC-3339, which is based on ISO-8601, and looks like this: 2024-06-11T15:00:00Z.

<title>Piccalilli</title>
<link href="https://piccalil.li/"/>
<updated>2024-06-11T15:00:00Z</updated>
<id>https://piccalil.li/</id>
<author>
  <name>Andy Bell</name>
</author>

Entries

In Atom, each post is an <entry>. Only id, title, and updated value are required, though you can optionally include author, content, link, summary, category, contributor, published, rights, and source. id must be unique for the entry and must not change.

<entry>
  <title>A quick and easy guide to Markdown</title>
  <link href="https://piccalil.li/blog/markdown-guide/"/>
  <id>https://piccalil.li/blog/markdown-guide/</id>
  <updated>2024-06-11T15:00:00Z</updated>
  <summary>This is the summary...</summary>
</entry>

JSON Feed

JSON Feed is the newest format discussed here and, as the name suggests, is JSON based rather than XML based. JSON Feed files should be served with the MIME type application/feed+json.

For an example of a JSON Feed, you can view the one for posts on my personal website: https://vale.rocks/posts/feed.json

Boilerplate and metadata

JSON Feed doesn't have much boilerplate compared to RSS and Atom. You must create an object, and that object must contain the JSON Feed version and a title. Though there are many optional values, many of which you should include: home_page_url, feed_url, description, user_comment, next_url, icon, favicon, authors, language, expired, and hubs.

{
	"version": "https://jsonfeed.org/version/1.1",
	"title": "My Blog"
}

Items

Items is represented as an array. The only truly required values are id — which uniquely identifies the item — and content_html and/or content_text. The optional values are url, external_url, title, summary, image, banner_image, date_published, date_modified, authors, tags, and language.

You can also provide attachments on an item.

"items": [
    {
        "id": "1",
        "content_text": "This is an item in the feed.",
        "url": "https://example.org/item-one"
    }
]

Auto-discovery

Many feed readers and other tools can automatically detect your feeds if you configure them correctly. You should add <link> tags to the <head> of your HTML to aide discovery.

<link rel="alternate" type="application/rss+xml" title="My Site's RSS Feed" href="https://example.com/rss.xml" />
<link rel="alternate" type="application/atom+xml" title="My Site's Atom Feed" href="https://example.com/atom.xml" />
<link rel="alternate" type="application/feed+json" title="My Site's JSON Feed" href="https://example.com/feed.json" />

Different tools interpret these tags differently. Some feed readers will, for example, provide users with the choice to select what feed they want from the provided options. Others will pick the first valid feed in the list, or pick the last. There is, unfortunately, very little consistency.

Implementation gotchas

Feeds are consumed by all sorts of tools in all sorts of contexts, so what works in one case might cause issues in another. It is important to stick close to the specs and consider defensive precautions.

Relative content

Feed readers are disconnected from your site. Relative links like <img src="/images/cat.jpg"> will often break because they are not relative to the website. Some feed readers may work around this problem, but you should convert all links (images, anchors, etc) to full, absolute URLs to ensure they work in all contexts.

Encoding

One of XML's most notorious attributes is that it is rather fragile. For example, if your blog post title is Tips & Tricks, and you put that raw into XML, it breaks:

<title>Tips & Tricks</title>

This is due to the & character being reserved. For cases like this, you have two main options:

1. Entity Escaping
   Convert special characters to their HTML entities.

   <title>Tips &amp; Tricks</title>
   

2. CDATA
   Wrap the whole thing in a CDATA block. This tells the XML parser, 'Ignore everything inside here. It's literally just text', which is great for the body of your content where you have lots of HTML tags and special characters, where it might be laborious to transform them.

   <description>
     <![CDATA[
       <p>Here are my <strong>Tips & Tricks</strong>...</p>
     ]]>
   </description>
   

Feed access controls

We often configure bot and scraping protection on our sites, but in this case we want our feeds to be scraped. We also likely want to make images and other resources able to be displayed in readers, so we may need to relax our protections. Our sites are also often served cached. Ensure your caching policy aligns with your feed updates — there is no point updating a feed if the cache means it won't reach readers!

Something else worth keeping in mind are security policies, such as CORS. While feeds are usually fetched server-side by aggregators, some web-based feed readers fetch feeds directly via the browser. Setting an Access-Control-Allow-Origin: * header on your XML/JSON files ensures these web-based clients don't get blocked by security policies.

There’s a great resource here to help you with CORS, by the browser-based RSS reader, Blogs Are Back.

Limited display

Many feed readers only display certain elements, such as text, images, and blockquotes, then apply their own formatting. This makes proper semantic HTML important, because non-semantic elements will not be understood or styled by readers.

The removal of provided formatting could cause issues if your content is complex or dynamic. In such a case, it can be worth only providing a summary or incorporating a notice directly into your feed noting that the content is best viewed on the web.

Validation and testing your feeds

Checking your feeds are proper by eye can be tricky, which is where validators are valuable.

• For RSS and Atom, you can use the W3C Feed Validation Service.
• For JSON Feeds, you can use the JSON Feed Validator.

These validators will catch those pesky date format errors and unescaped content instantly. There are also many libraries and other tools out there that you can incorporate as part of your processes so that broken feeds are caught before they can hit production.

You should also try opening your feeds in a few feed readers and other syndication feed tools, just to confirm all works without issue — much like you already test a website across a few browsers.

Wrapping up

This article has only skipped along the top of the syndication feed ocean but has hopefully given you a level of knowledge ready to start building feeds. Having feeds for your content is not just vital for distribution but also contributes to a strong and healthy web.

If you're looking to dive deep into the feed ocean, these further reading links will hopefully provide you with some solid entry points:

• RSS 2.0 Specification
• Introduction to Atom
• RFC 4287: The Atom Syndication Format
• JSON Feed Version 1.1 Explainer

At some point I got very invested in accessibility, because it was the missing link for me in my profession. Suddenly, the things I built not only looked good, but they also worked as expected when using a keyboard and a screen reader. Slowly, practicing web development with accessibility in mind became the new normal for me. Unfortunately though, accessibility is still far from normal in the tech industry.

Before I get into the craft, technical aspects and how to sneak fixes in, I would first like to address that a major inspiration for this piece was The Accessibility Operations Guidebook by Devon Persing.

Ableism (in the tech industry)

If you haven't heard this term before, here's a summary from the Wikipedia on ableism:

Ableism […] is discrimination and social prejudice against physically or mentally disabled people. Ableism characterises people as they are defined by their disabilities and also classifies disabled people as being inferior to non-disabled people.

In the following, I will try to use my own experiences to illustrate when I have encountered ableism during my job.

Medical model of disability

Whenever I brought up the topic and pointed out barriers, it was assumed that these barriers arose or existed because people with disabilities were using the product. So the fault lies with the people, not the product.

This is the medical model of disability, which assumes that people, rather than their environment, are the problem:

This model links a disability diagnosis to an individual's physical body. The model supposes that a disability may reduce the individual's quality of life and aims to correct or diminish the disability with medical intervention.

As long as you can operate everything with the mouse and you can still somewhat recognise the light grey font on a white background with font size 10, everything is fine, right? This attitude is ableist because, among other things, it excludes not only keyboard users but also people with poor, or even no vision.

People with disabilities don't use the product anyway, so why invest time and money to make it accessible to a few blind people, right? This attitude is also ableist, because in Germany alone, the official number of people with severe disabilities is 7.9 million, and the real number is very likely much higher. From an economic point of view alone, it makes no sense to ignore the potential purchasing power of these people.

Wikipedia explicitly addresses this very attitude:

In ableist societies, the lives of disabled people are considered less worth living, or disabled people less valuable, even sometimes expendable.

This ableist attitude is reflected in statements such as “We don't have any customers with disabilities.” or “We don't have any blind users, so it doesn't need to be keyboard-accessible.” These and many other myths are debunked on the Accessibility Myths Debunked website. Fortunately, there is also a counter-model for this, namely:

Social model of disability

The social model of disability is summarised as follows on Wikipedia:

The social model of disability proposes that people are disabled by systemic barriers, negative attitudes, and social exclusion, rather than by their own physical or mental differences.

Here, we recognise that the problem is not people with disabilities who can only use the product to a limited extent or not at all. Instead, it shows us that we ourselves have created these barriers through our ableist attitudes.

This realisation can lead us to start making real changes and improvements, starting with the people, through the tools we use every day, to the product we create.

My personal recommendation is always to start with the six most common problems and then continue with the Easy Checks. Many so-called “low hanging fruits” can be detected using automated tools such as ARC Toolkit, Axe DevTools, and WAVE. This makes it easier to document and fix problems at the beginning before tackling more complex issues where these tools reach their limits.

However, we still need to dig deeper to understand why this article you’re reading right now, exists in the first place.

With a few exceptions, the teams I work in have been, and continue to be predominantly white and male. This is certainly also due to the fact that I live and work in Germany, which is why I asked my friends who also work in development how diverse their working environment is.

Their situation is similar to mine (they also live and work in Germany), and they too have noticed that female colleagues are more likely to be found in the design, marketing, and management departments. In development, however, their colleagues are also predominantly white and male, which brings me to the next topic:

Battling against ableism in the tech industry

In her essay White Supremacy Culture, Tema Okun touches on many topics that overlap with my professional career as a front-end developer. Lots of companies seem to have embodied and implemented these awful characteristics and from what I can tell, this seems to be the default behaviour. The Wikipedia article on her essay lists 15 characteristics, of which I will quote three that I have experienced myself:

Sense of urgency: Emphasising speed and immediate results at the cost of thoughtful reflection or long-term solutions.

Who among you has been told that there is no time or money to make the product accessible? Or that it will be done later because it has to go live now due to pressure from management and/or stakeholders?

This move fast and break things attitude leads to products reaching the market that were created for the majority but exclude minorities. In addition, in the long term, it can lead to enormous time and cost expenditures if accessibility is only considered at the end of the cycle.

If companies shift to the left instead and work according to the motto “Slow is smooth. Smooth is fast.” they will not only aim to create the most inclusive product possible, but also offer added value in other areas:

• You reach a larger customer base
• The risk of being sued can be vastly reduced or even completely eliminated
• By focusing on accessibility, product quality and employee mindset can be greatly improved

The whole team is responsible, not just the development team. We can only make lasting changes and avoid making people responsible if we take a comprehensive approach that includes everyone.

Quantity over quality: Prioritising "things that can be measured" over things that cannot, such as relationships and conflict resolution.

It is now (for better or worse) normal for websites to measure where people click, how long they watch videos, whether they skip certain sections, and so on. Thanks to automated testing, many accessibility issues can also be recorded as metrics. However, this does not mean that a product is 100% accessible as soon as these tests no longer show any errors! You can build the most inaccessible website with a perfect Lighthouse score, as Manuel Matuzović has impressively proven. Automated tests are an indicator of how compliant something is, but not how well people can actually use it.

That's why it's very difficult, if not impossible, to quantify the return on investment (ROI) for accessibility. So-called “invisible wins” are particularly difficult to sell if the focus is not on the structure, but only on the appearance of a product.

If you just click through with the mouse, quality of life improvements such as consistent, clearly visible keyboard focus, landmark elements, and the correct use of WAI-ARIA unfortunately go unnoticed.

Simply taking these three things into account can lead to more people being able to use the product, regardless of whether they have a disability or not. This can lead to more satisfied customers, who are very likely to recommend the product to others. This can expand the customer base, which in turn can lead to increased sales.

Only one right way: Believing that there is only one correct way to do things, excluding diverse approaches and perspectives.

One of the websites I share most often is The ideal viewport doesn't exist. It uses real data and practical examples to show us that it no longer makes sense to stick to the rigid concept of breakpoints. How are you supposed to know what screen width a “desktop,” “tablet,” or “phone” has?

Doesn't it make much more sense to be the browsers mentor, not its micromanager? We have long had the ability to implement fluid typography and UI that adapts to the respective screen widths. CSS allows us to do this thanks to custom properties, the clamp() and minmax() functions, and container queries.

The advantages are as numerous as they are obvious:

• No need to think up or research arbitrary breakpoint sizes. A design is created for the maximum and minimum width, and browsers take care of everything in between.
• Realising that the pixel-perfect approach is like chasing the dragon: it's the pursuit of an unattainable goal. Designs for websites are just paintings of them. Actual software is alive; it responds, it adapts, it moves, it errors, it loads.
• The amount of CSS code can be drastically reduced because edge cases no longer need to be taken into account. Cascade layers could then be used for fine-tuning.
• The code base is easier to read, more robust, and future-proof because these features tend to be used more in the foreseeable future.

Am I making sense here? I think I do! After I made this pitch, however, the reactions were mostly “but we've always done it this way” (love this one) or “But what breakpoint sizes do we use then?” in addition to huge question marks above the heads of the respective recipients.

My suggestion to modify a small side project or the current main project according to this principle was often rejected because the concept is too new, too alien and people would have to move out of their comfort zone and adapt their way of working.

After dealing with these uncomfortable topics that need to be addressed and discussed, and perhaps feeling that it is impossible for you to bring about any change, you may ask yourself the following:

Why would you do it if it’s not part of your job?

Perhaps, like me, you are officially a front-end developer and your contract more or less specifies your area of responsibility. So why should you be doing the work of an accessibility practitioner / designer / engineer? My answer is always: because it's part of the work.

Among all the things that lead from the initial idea to the final website, I don't see any distinction between ‘normal’ work (i.e. what's in your contract) and work in the realm of accessibility. Three examples from the top of my head to get my point across:

1. The work is not done if the thing we are working on cannot be operated with a keyboard
2. The work is not done if complex widgets do not have a meaningful semantic role and an accessible name
3. The work is not done if there are problems with colour contrast because the brand colours are always to be used

As already mentioned, accessibility is not yet as normalised as many other topics. But if it is as important to you as it is to me, you will have to ask yourself another question:

Why wouldn’t you tell your boss?

Here, too, the answer can be complex and individual. A few possible scenarios could be:

It’s not part of your job description

If your employer thinks that accessibility isn't part of your job and is something separate, then they're not entirely wrong. If you're dealing with this issue at management level, for example, in order to integrate it into all processes throughout the company, it really is a full-time job. But I digress!

Your contract does not explicitly state that accessibility is part of your job, and you don't want to fall out with your employer. It may also be that you have a very strict employer, which would be another reason to keep it secret.

“No time and money for accessibility”

One of the most popular myths! This one is also disproved succinctly at Accessibility Myths Debunked:

It may not be the case if accessibility is considered from the beginning of the project and a development team has proper skills. When accessibility has become a habit, the development time doesn't change or changes a little.

Unfortunately, that doesn't change the fact that your boss insists on it and you feel compelled to improve the website behind their back.

No interest or pushback

“I don't give a damn about accessibility, I'm not interested in it! But I think it's good that you're involved in it and know about it.”

This is something a front-end developer once said to me. They simply have no interest because they have never used a website with a keyboard in their lives or are firmly convinced that it only affects people with disabilities, who are not their customers anyway. Could this be because the website is not accessible? Maybe, but I don't want to digress again!

They may even react irritably or go on the offensive when you bring up the subject. This can happen very quickly when you show people that they have an ableist approach to an issue. Caution is advised here, because it can quickly become personal. That would be another reason to take a low-key approach to the issue.

Do these scenarios sound familiar, and do you still see it as your responsibility to make the product you are working on as accessible as possible, even though it is not officially your job? Then, in the following sections, we will discuss how to find allies and work with them to create leverage.

Culture, climate and power lines

In this scenario, we assume that we will not receive any support “from the top” and will have to organise ourselves like a grassroots movement from the bottom up. For this to work, we need allies, no matter how big or small our company is. This will not only help us to distribute tasks and responsibilities, but also reduce the potential psychological pressure that can come with it.

To understand how we can reach and communicate with the respective people, we need to understand the difference between culture and climate and how we can use power lines for our purposes. The following quotes are taken directly from The Accessibility Operations Guidebook by Devon Persing:

Organisations are impacted both by their culture, which is driven by a minority in leadership, and their climate, which is driven by the majority of people in the organisation. Resources, support and information flow through organisations along power lines.

She further explains that “organisational culture is formal and systemic”, while “organisational climate is informal, a kind of ‘shared perception’ of the organisation’s day-to-day”.

People in official leadership roles create an organisation’s culture. They communicate this culture to other members through management.

This can be understood as the “official stance of the organisation”, like a mission statement, for example. It is “perpetuated in the same way it is in the larger culture, with ceremonies and rituals (meetings, events) and institutional myths (stories) by leadership.”

Climate, in comparison to culture, is less official. It’s a vibe. It’s the feel of the organisation, how structured or loosey-goosey it is.

This describes “how much freedom workers really have, and how much actual support they have from leadership to try new things or make the workplace better.”

She continues by explaining that culture (top) can obviously can push down on climate (bottom), but that climate can also push up on culture.

One example for the former is “an organisation requiring workers to return to corporate offices with the supposed end of the COVID-19 pandemic, despite public opinion and scientific data supporting the positives of working from home.”

Healthy and Happy Working from Home? Effects of Working from Home on Employee Health and Job Satisfaction

An example for the latter is “the wave of diversity, equality and inclusion (DEI) efforts that happened because of Black workers’ need to hold space around ongoing and escalating police brutality.”

How the Black Lives Matter Movement Enhanced Corporate Governance in 2020

In an organisation, power lines are usually connected to people like managers who represent their teams or departments. […] The way that culture and climate can push each other is a form of power […]

She explains that “power lines are usually connected to people like managers who represent their teams or departments.” and she’s mentioning specialists, meaning people that have a focus on a certain topic, who can “become conduits for these types of lines, too”.

In case of the (accessibility) specialist, she’s warning that it can be “easy to become a bottleneck for other people while you’re trying to do accessibility work across an organisation, even if that’s not your intent.”

With this basic understanding, let's look at the most important point so that we can successfully sneak in accessibility fixes without telling our boss.

Finding allies

I'll be honest with you: I can't give you bulletproof instructions on how to find allies in your company because it depends on so many variables, including (but not limited to):

• Your personality, professional experience, expertise, and rhetorical skills
• The culture and climate in your current company
• The personality, professional experience, expertise, and rhetorical skills of your colleagues

Instead, I'll tell you a few anecdotes about how I've been able to make a difference in the area of accessibility, sometimes more, sometimes less.

Being upfront

As I wrote at the beginning, it was only during the course of my career that I began to focus clearly on the topic of accessibility. At a certain point, I made it very clear in interviews (for permanent positions and freelance jobs alike) that I would be concentrating on this area.

My pitch was more or less what I wrote under Why would you do it, if it’s not part of your job? I also made it clear that I work holistically and don't see the topic as my sole responsibility. It affects development, design, management, human resources, and other departments equally.

When I was first introduced to a team, it was mentioned that I was very knowledgeable about the topic and an expert (which is not true, and I clarified that right away). I was also allowed to repeat my pitch in front of the assembled team, which signalled to interested colleagues, “Aha, he's one of us!” or “Nice, I have a few questions on the topic.”

From that point on, I was “the accessibility guy,” which can have advantages, but also disadvantages, as some colleagues might associate it with something negative. Very often, people approached me proactively afterwards or were very open when I talked about it. Not just developers and designers, but also product owners and marketing people!

Sharing knowledge

As mentioned earlier, I don't see it as my responsibility to carry the burden of this issue alone. That's why I first check the respective communication tool (Slack, Teams, etc.) to see if there is a channel for accessibility so that I can share knowledge.

Unfortunately, in the past, creating this channel and inviting people has not been very effective. Either the topic is too overwhelming for them, or they are not interested because it is not directly related to their daily business. More often than not, I was just screaming into the void, and there was no real interaction except for an emoji here and there.

Since we are pursuing a grassroots movement approach, I recommend instead looking for a channel where knowledge is actively shared among developers and/or designers. Maybe there are even a few people from management in this channel! In any case, this channel must be alive.

Here I often share articles that I read in my favourite newsletters: Accessibility Weekly, Web Weekly, and of course The Index. These sources provide enough material to keep the digital fire burning and share something at least once a week.

Showing examples

I had the biggest breakthroughs when I showed people directly on the respective product what positive effects improved accessibility can have.

In development, it was for example the use of native elements instead of third-party solutions. Everyone in this department is happy when even more dependencies and potential security risks are not added to package.json. Another great example for low effort and big impact: Landmark elements!

Even seemingly small things like using headings correctly can have a big impact. Especially after I navigated them with a screen reader and explained why it is so important for users of this software. Some people were amazed that screen readers exist and that content can be consumed in this way!

Using the Stark plugin for Figma, I was able to show designers how they can take this topic into account during creation and handover. I even wrote an article about it, “Fuck off” to hand-off: Holistic web design.

Different roles require different techniques

I'm an RPG fan, by which I mean Final Fantasy 7 to 12, Dragon Quest, Ni No Kuni, you name it. That's why in this section I'm introducing four roles (or avatars?) that have specific skills to promote accessibility within the organisation.

Depending on our role in the company, our skills and allies, and how much support we receive from our colleagues, we can take on different roles.

A role also depends on when we join a project. The earlier we become involved, the more likely it is that we will have taken on every role at some point.

The adviser

This is my personal favourite role, because it allows us to avoid future mistakes and do a lot of educational work.

Is the project supposed to be a simple landing page that won't really be maintained by the customer, or hardly at all? Then we can advise against using heavyweights like React or Vue.js and instead recommend a static site generator like Astro or Eleventy (now called Build Awesome).

Do your colleagues want to use a UI library to speed up the design and development process? Fair enough, but it should be tested beforehand to ensure that it is accessible and that, in individual cases, components can be replaced with native HTML elements.

This stage of the process is also a good time to talk about progressive enhancement. Not only does it bring many benefits for users, but it will also increase the skill level of the designers and developers involved.

The mediator

This role can overlap somewhat with that of an adviser, depending on how open and flexible the designers are, how good our communication skills are, and how much time is available for any changes.

At this stage, designs have already been created and are ready to be handed over to development. Ideally, they will first be reviewed by a developer and only passed on once all changes have been implemented and the go-ahead has been given.

Here, too, we can do a lot of educational work on the topic of progressive enhancement, explain the power of native HTML and CSS, and suggest tools that make the handover even smoother. The goal is to minimise follow-up questions from the development team so that they can get started right away.

The article Accessibility for designers: where do I start? by Stephanie Walter is a treasure trove for exactly this scenario, providing you with the resources you need to support your designers. I also strongly agree that the time for designers to learn to code is now.

The smuggler

The following example comes from Amber Hinds, thank you for sharing!

We have clients who really care about SEO, some of whom are legacy clients on marketing retainers. Because there's so much overlap, we are able to use SEO hours to fix accessibility. We put our Accessibility Checker WordPress plugin on the site to find issues and fix things like empty links, links with ambiguous anchors, headings out of order, empty or missing alternative text, etc. I don't think that these clients would ever sign up for an accessibility retainer, but because of SEO we can do it.

We often slip into this role when we’re actively working on development and can make various small to medium fixes that don't slow us down in our main task.

This is not only a good “selling point” for our superiors, but also another opportunity to show our colleagues, using practical examples, that accessibility doesn't have to be difficult.

During these sneaky fixes, wen can often notice larger, global problems, such as:

• Insufficient colour contrast and font sizes
• Poorly recognisable or non-existent keyboard focus
• Missing or incorrectly used landmark elements

These should at least be documented and, best case, turned into a ticket that can be dealt with in a timely manner so they won’t catch dust in the backlog.

The hacker

This role is exclusively for developers and overlaps somewhat with the adviser role. It can be a rather passive role, as we ask, for example, whether an accessibility linter is used in the code editor (very often Visual Studio Code or JetBrains) to identify potential problems during development.

Or whether an accessibility linter can be integrated into a pre-commit hook so that non-accessible code cannot be pushed in the first place. Another option would be to add this linter to the pipeline.

Regardless of whether it is part of the definition of done (if there is one) or not: as soon as we find potential accessibility issues during a code review, we should at least leave a comment.

Best case, we can mark the respective pull request as “not approved” until the issue has been resolved. However, a delicate touch and open, transparent communication with our colleagues is important here so that they don't wonder why we have commented on code that is OK for them but not for us.

Wrapping up

This article shouldn't exist. Accessibility should be as normal in conversation as performance, security, SEO, and “AI”. Unfortunately, the tech industry has a big problem with ableism and white supremacy, which is why I wrote this article.

Understanding the culture, climate, and power lines within your organisation can help you find allies so you can organise like a grassroots movement from the bottom up. You can take on different roles to support each other, share knowledge and bring about change without the man noticing.

The most important tool when it comes to accessibility is not browser extensions, newsletter subscriptions, or screen readers. They play an important role, but none is as important as the community you have around you. Always make sure you're on the same page as your allies and that you're all working toward the same goal, even if you might take different paths to get there.

Chrome’s announcement post demonstrates how, if we were using anchor positioning, we could use anchored container queries to query the currently active fallback position (if any). They’ve provided a little demo in the post where a toggletip caret is anchored to the side of a toggletip, but if the toggletip needs to be anchored to a different side of the trigger due to lack of space, the caret is anchored to a different side as well. So in this case, anchored container queries are used to determine which position the toggletip is in, so that we can position the caret accordingly.

This is a pretty good use-case for anchored container queries, but also a great opportunity to look at how we might build toggletips in the (hopefully) near future. You’ll learn about popovers and anchor positioning, which are already baseline and will ensure that the toggletips at least work, as well as declarative anchors, ‘modern’ attr(), and corner-shape, progressive enhancements enchantments that provide a range of magical benefits.

Here’s what we’ll be making:

See the Pen Anchored container queries demo by Andy Bell (@piccalilli) on CodePen.

In Chrome you’ll see toggletip carets that flip to the appropriate side depending on the amount of space available, but in other web browsers you’ll get the toggletips without carets.

Let’s get into it!

Setting up the popover and anchor associations

We’ll be using popovers to mark up the toggletips, as that’s the semantic way to do so these days, but before we begin it’s worth mentioning that they’re implicitly anchored. However, since you might want to use anchored container queries without popovers, I’ll show you how to set up anchor associations anyway.

To set up the popover and anchor associations in a declarative but progressively enhanced way, we’ll need the following HTML markup:

<div anchor="leftButton" id="--leftPopover" popover>Toggletip</div>
<div anchor="centerButton" id="--centerPopover" popover>Toggletip</div>
<div anchor="rightButton" id="--rightPopover" popover>Toggletip</div>

<button id="leftButton" popovertarget="--leftPopover">Button</button>
<button id="centerButton" popovertarget="--centerPopover">Button</button>
<button id="rightButton" popovertarget="--rightPopover">Button</button>

The most familiar part of this is probably the popover markup. We’ve given the toggletips the popover attribute, and then an id so that each trigger can reference a popover using the popovertarget attribute. The strange part is that we’ve used custom-ident values (e.g., --leftPopover), but I’ll explain why shortly. That’s the popover functionality set up.

For the anchor positioning we’ve also given ids to the triggers, and then referenced them from anchor attributes set on the toggletips. These values don’t have to be custom idents.

However, for web browsers that don’t support the anchor attribute, we’ll need to use CSS instead, and there’s a shorter and a longer way to do that depending on whether or not modern attr() is supported.

The shorter, modern attr() way:

/* Modern attr() supported */
@supports (x: attr(x type(*))) {
  button {
    /* Reuse the name from popovertarget */
    anchor-name: attr(popovertarget type(<custom-ident>));
  }

  [popover] {
    /* Anchor to the relevant button */
    position-anchor: attr(id type(<custom-ident>));
  }
}

Basically, if modern attr() is supported, we reuse the popovertarget values of the buttons as anchor names while making it clear that we want to parse them as custom idents. After that, we match the id values of the popovers to said anchors, thus setting up the anchor positioning associations. The anchor-name and position-anchor CSS properties only accept custom idents (e.g. --leftPopover), so that’s why we're making a big fuss about them.

Next, if modern attr() isn’t supported, name each anchor manually:

/* Modern attr() not supported */
@supports not (x: attr(x type(*))) {
  /* Assign anchor name */
  #leftButton {
    anchor-name: --leftButton;
  }

  /* Anchor to button */
  #leftPopover {
    position-anchor: --leftButton;
  }

  /* And so on... */
  #centerButton {
    anchor-name: --centerButton;
  }

  #centerPopover {
    position-anchor: --centerButton;
  }

  /* And so on... */
  #rightButton {
    anchor-name: --rightButton;
  }

  #rightPopover {
    position-anchor: --rightButton;
  }
}

Once modern attr() is Baseline widely available, we can delete this block, and then once the anchor attribute is Baseline widely available, we can delete all of this CSS. You won’t even need to use custom-ident values, so --leftPopover can become leftPopover, for example.

Note: if we’d rather that the toggletips be triggered on :hover (making them tooltips instead of toggletips), we can swap popovertarget for interestfor, but note that interest invokers are only supported in Chrome 142 and above. Keep them in mind for the future!

Aligning and styling the toggletips

Like last time, I’ll drop the code right here so you can skim through it before we look at it line-by-line:

[popover] {
  position: fixed;

  /* Align to right/implied center */
  position-area: right;

  /* If no space, flip to other inline side */
  position-try: flip-inline;

  /*
    1rem of spacing between the button and
    toggletip that also flips side accordingly
  */
  margin-inline-start: 1rem;

  /* Anchor toggletip caret to this */
  anchor-name: --toggletip;

  /* Used to query this container’s fallbacks */
  container-type: anchored;

  /* Scooped corners, if supported */
  @supports (corner-shape: squircle) {
    border-radius: 3rem;
    corner-shape: squircle;
  }

  /* Normal corners, if not supported */
  @supports not (corner-shape: squircle) {
    border-radius: 1rem;
  }
}

First, we must declare position: fixed on the anchored element (in this case though, popovers already have it).

Next, we need to position the toggletip relative to the button (let’s say the center-right) using the position-area property. Now, you might think that position-area: center right is the correct declaration here, but here’s what that actually does:

As you can see, it’s overflowing the center-right tile, which is wrong but forgiving, since web browsers declare align-self: anchor-center under the hood to make it work anyway. This is declared on what’s called the Inset-Modified Containing Block (IMCB), which again is the center-right tile.

However, for reasons unknown, web browsers aren’t so forgiving when a fallback position is activated. The trick is to use position-area: right instead. By omiting the center keyword, it resolves to position-area: span-all right, which does this:

Now the toggletip does fit into the tile (IMCB). And again, it’s vertically aligned within the center of it due to align-self: anchor-center.

We can safely use position-try: flip-inline, which turns right into left whenever the toggletip overflows the viewport. Later on, anchored container queries will query whether this is happening or not.

After that, margin-inline-start: 1rem adds 1rem of spacing between the button and the toggletip at the start of the inline axis, which also flips accordingly.

anchor-name: --toggletip turns the popovers into anchors so that we can create toggletip carets and anchor them to said popovers. Normally this’d be a naming collision waiting to happen (because three different popovers are now called --toggletip, right?), but the toggletip carets will be nested inside the popovers, so they’re somewhat scoped.

And remember, we’ll be flipping the toggletip’s caret to the opposite side whenever the toggletip is flipped, and that’s what container-type: anchored is for — it’s a totally new type of container and we’ll be querying it’s fallback position to determine the correct side.

One more thing, though…

If corner-shape: squircle is supported (@supports (corner-shape: squircle)), then we use it with border-radius: 3rem to create corners that aren’t quite rounded but aren’t quite square either. If it’s not supported then we just use border-radius: 1rem. This is optional of course, but corner-shape will play a bigger role when we use it again in a moment:

/* Scooped corners, if supported */
@supports (corner-shape: squircle) {
	border-radius: 3rem;
	corner-shape: squircle;
}

/* Normal corners, if not supported */
@supports not (corner-shape: squircle) {
	border-radius: 1rem;
}

Creating and positioning the toggletip’s caret

Similar to how we anchored the toggletips to the buttons, the following code anchors the toggletip carets to the toggletips:

[popover] {
	/* Previous section code */

  /* Toggletip caret */
  &::after {
    /*
      Only create carets if anchored
      container queries are supported
    */
    @supports (container-type: anchored) {
      /* Create caret */
      content: "";

      /* Anchor to toggletip */
      position: fixed;
      position-anchor: --toggletip;

      /* Scooped carets, if supported */
      @supports (corner-shape: scoop) {
        height: 1rem;
        aspect-ratio: 1/2;
        corner-shape: scoop;
        background: inherit;
      }

      /* Normal carets, if not supported */
      @supports not (corner-shape: scoop) {
        /* Hack to create a triangle */
        width: 0;
        height: 0;
        border-top: 0.5rem solid transparent;
        border-bottom: 0.5rem solid transparent;
      }

      /* If no fallback */
      @container anchored(fallback: none) {
        /* Position caret on the left */
        position-area: left;

        /* Needed for scooped carets */
        @supports (corner-shape: scoop) {
          border-top-left-radius: 100% 50%;
          border-bottom-left-radius: 100% 50%;
        }

        /* Needed for normal carets */
        @supports not (corner-shape: scoop) {
          /* Part of the triangle hack */
          border-right: 0.5rem solid var(--toggletip-color);
        }
      }

      /* If flip-inline fallback triggered */
      @container anchored(fallback: flip-inline) {
        position-area: right;

        @supports (corner-shape: scoop) {
          border-top-right-radius: 100% 50%;
          border-bottom-right-radius: 100% 50%;
        }

        @supports not (corner-shape: scoop) {
          border-left: 0.5rem solid var(--toggletip-color);
        }
      }
    }
  }
}

First of all, the toggletip carets are CSS-generated using the ::after pseudo-element:

[popover] {
  &::after {
    /* Toggletip caret */
	}
}

Then, within that, we need to see if the web browser supports anchored container queries (if not, the toggletip carets simply aren’t generated, although the toggletips will still work):

[popover] {
  &::after {
		@supports (container-type: anchored) {
	    /*
	      Only create carets if anchored
	      container queries are supported
	    */
		}
	}
}

Within that, content: "" generates the toggletip carets (or, rather, it generates a pseudo-element with no content that we’ll style into carets).

position: fixed and position-anchor: --toggletip anchors them to the toggletips.

After that, we again leverage corner-shape to create scooped toggletips. Or, if corner-shape isn’t supported, then we use the classic border trick to create triangle-shaped carets.

We also — finally — implement those anchored container queries to position the carets to the correct side of the toggletips. When a fallback isn’t active, @container anchored(fallback: none) will match, but when a fallback is active, @container anchored(fallback: flip-inline) will match. The value of fallback simply needs to match a value of position-try:

position-try: flip-inline, in our case

/* Scooped carets, if supported */
@supports (corner-shape: scoop) {
	height: 1rem;
	aspect-ratio: 1/2;
	corner-shape: scoop; /* (Border radius is set later) */
	background: inherit;
}

/* Normal carets, if not */
@supports not (corner-shape: scoop) {
	/* Hack to create a triangle */
	width: 0;
	height: 0;
	border-block: 0.5rem solid transparent; /* (Side is set later) */
}

/* If no fallback */
@container anchored(fallback: none) {
	/* Position caret on the left */
	position-area: left;

	/* Left border radii for scooped carets */
	@supports (corner-shape: scoop) {
		border-top-left-radius: 100% 50%;
		border-bottom-left-radius: 100% 50%;
	}

	/* ‘Left’ border for normal carets */
	@supports not (corner-shape: scoop) {
		border-right: 0.5rem solid var(--toggletip-color);
	}
}

/* If flip-inline fallback triggered */
@container anchored(fallback: flip-inline) {
	position-area: right;

	/* Right border radii for scooped carets */
	@supports (corner-shape: scoop) {
		border-top-right-radius: 100% 50%;
		border-bottom-right-radius: 100% 50%;
	}

	/* ‘Right’ border for normal carets */
	@supports not (corner-shape: scoop) {
		border-left: 0.5rem solid var(--toggletip-color);
	}
}

As a reminder, here’s the final demo:

See the Pen Anchored container queries demo by Andy Bell (@piccalilli) on CodePen.

Wrapping up

Container queries are evolving beautifully, especially with the newest addition, anchored container queries. And, thanks to other modern CSS features such as the anchor attribute, ‘modern’ attr(), corner-shape, and even interest invokers, we can include all kinds of progressive enhancements to create some really awesome — in this case — toggletips.

If you want to go ahead and implement this (full code in the demo), you totally can. If something isn’t supported it’ll simply revert to something that is, and then as new features become baseline, you can very easily remove the code that’s no longer needed.

Missing an accessibility-first community

It's hard to put into words how lonely it is when you’re the only person ensuring that there aren't click handlers on generic elements. I've come to accept that the bar for "accessibility advocate" is just "still cares about accessibility in spite of it all." I'm used to being the only one giving accessibility feedback when joining a new project. It's exhausting having to explain the same small issues over — the same issues that are easily caught by automated accessibility testing tools. Sometimes, it's tempting to just delete the repository and start over.

When you know anything about digital accessibility, you know that compliance doesn't always have to be a never-ending slog of fixes. It can be baked in from the start.

In many ways, I am lucky. At work, my recommendations are respected and my coworkers want to learn. When I come across hard questions, I can always reach out to former coworkers from my previous job at a digital accessibility company. When I need someone to check my assumptions, I just talk to the accessibility expert friends who always support me. I’ve never asked for permission to fix accessibility issues or build accessibly because accessibility has consistently improved the user experience, that’s worked in my favor.

Recently however, I got the chance to catch up with some of my former coworkers. There was a moment when I said "I don't know if the automated captions are better or worse." One of them responded "Yeah, they're really wrong - a live captioner would be a lot better." I closed my eyes, leaned back in my chair, and sighed "It's nice not to have to explain." Then, I remembered how nice it was to have a live captioner in our meetings. The next week, I started looking at expensive certifications. I wanted a reason to start learning deeply about accessibility again.

Finding an accessibility-first community

When I joined npmx the next month, I was curious and hoped I'd get to learn from brilliant developers. At VueConf 2025, I had learned that Daniel Roe wrote a script that automatically registers an npm package every time he buys a domain. I figured he’d probably know a thing or two about npm.

From an accessibility standpoint, I was expecting more of the same. I assumed I would still be the only person insisting "accessibility is a right, not a privilege." Explaining that screen reader users use several lists of things to navigate a webpage: links, headings, landmark regions. That’s why your <header> should be outside of <main> and your link text shouldn’t all be “click here!”

Inside the npmx Discord, I didn't expect to see a dedicated accessibility channel. I was delighted to see automated accessibility tests when I opened up my first pull request for review. There were other people already hard at work making sure there were no click handlers on generic elements. I started to feel things that I hadn't felt since working in digital accessibility full time.

Immediately, I started learning deeply about accessibility again. Some things were small, like HTML’s struggle with headings inside <details>/<summary> but I was also getting to have the big conversations about architecture and design that I missed having. I didn’t even have to explain what a VPAT was. Most importantly, our conversations are being treated as important. If there's a possible accessibility issue in another conversation, accessibility experts are tagged in. It’s all filling a bucket I hadn’t even realized was empty.

Of course, there are things we weren’t able to fix before the alpha release — that’s how software is: perpetually unfinished, never 100% accessible — but I don’t have to justify a fix with a business logic bug because we’re already auditing. Earlier this week, someone asked how the accessibility channel felt about accessible color contrast. I had already typed out a justification for sufficient color contrast before I realized it was an invitation to review a pull request.

Wrapping up with some tips for building an accessibility-first culture

For many reasons, the first step is writing documentation. In your onboarding documentation, encourage developers to install accessibility linters. Document the accessibility problems you’ve already solved, patterns for interactive controls and colors that have sufficient contrast together.

Bonus points if you have the documentation available in multiple forms (e.g. text, diagrams, and videos).

Tests are another form of documentation and useful for preventing regressions and always use accessibility testing tools. Write your components and types in ways that enforce accessibility. An <input> should always have a label, so the labelText prop for your component with an <input> should be required, right?

Think of accessibility concerns as early as possible, such as in the design and planning phases. Accessibility auditing is part of quality assurance (QA). If you have the budget, pay accessibility testing experts to do manual testing and also, testing with users with disabilities. When accessibility experts raise concerns, take them seriously. Also celebrate the little wins — sufficient color contrast and alt text mean a lot to a lot of people.

Finally, respond with humility when you get it wrong, because you will get it wrong. Use those moments as learning and improvement opportunities because your ultimate goal should be inclusion. It makes a lot of sense listen to the people who are excluded.

Well, we've aimed to address and highlight all of that in a homepage redesign that we've just launched.

As you can see, we're not messing around in terms of our positioning and messaging. I'm really confident we're hitting the appropriate tone for 2026 too. We're already clear on our stance on AI/LLMs, but we also wanted to really highlight that with this redesign, so people know — right from the start — what we're all about.

We know we're sailing against the current here, but we're cool with that. Being unapologetically for the web platform and progressive enhancement since day one has always had us sailing against the current. We've just got bigger sails now to go against the onslaught of AI-boosting by providing really high quality educational material for humans, written by humans, always.

That's exactly what we do here.

Check out the new homepage