While it is easy for sighted people with full mental and motor abilities to click a button with a mouse to display more information, users of Assistive Technology (AT) may have a completely different experience with the same action.

The information an expandable button conveys to AT depends heavily on the context. This context also dictates which ARIA attributes should (or should not) be used. Often, the patterns are very similar in their functionality and interpretation and can be interpreted differently by me than by you.

When I conduct accessibility audits, I usually can’t avoid having to check an element that has the aria-expanded attribute. One of the challenges I faced was determining what kind of pattern this was, whether aria-expanded was appropriate here, or if it could even be replaced by a native HTML element.

This article is intended to help you more easily determine whether aria-expanded has been used correctly or not. It’s not about how to implement every pattern discussed here in a production environment! However, in each section, I’ve included additional links so you can dive deeper into the topic.

The two categories

As I understand it, collapsible widgets can be divided into two categories: collapsible sections and collapsible interactive elements.

These two categories include patterns that are sometimes very similar, but not identical. In addition, there are patterns that can also reveal and hide content, but these do not require the aria-expanded attribute.

Collapsible sections

This category contains two patterns: Accordion and disclosure widget. The former is based on the latter, so let’s take a closer look at the disclosure widget first.

Disclosure widget

<button
	aria-controls="content"
	aria-expanded="false"
	type="button"
>
	Show more
</button>
<div id="content" >
	<p>I am hidden no more!</p>
</div>

This is a basic disclosure widget that requires JavaScript to dynamically change aria-expanded from true to false and to add keyboard support.

aria-controls serves as optional support here to establish a direct link between the button and the content. For more information on implementation, see Adrian Roselli’s article Disclosure Widgets.

However, if that is all it needs to do, it is recommended to use the <details> and <summary> elements. These two native HTML elements work in all major browsers and are also recognised by AT.

Accordion

The accordion pattern is more complex because it combines multiple disclosure widgets. Here, too, aria-expanded is required to communicate the current state to assistive technologies.

There is also often the “exclusive accordion,” which only allows one disclosure widget to be open at a time and closes the others. Not only has Eric Eggert expressed legitimate doubts about this in his article Exclusive accordions exclude, but Steven Hoober also explains in Designing for Progressive Disclosure why this is a user-hostile pattern.

If you still need to build one, it’s recommended to try out Alexander Lehner’s solution in Let’s Play Accordion with the HTML details element. Alternatively, Heydon Pickering also has a suggestion on how collapsible sections could be implemented.

Collapsible interactive elements

A collapsible section can also contain interactive elements such as links, but this pattern is most often used to hide large amounts of text in order to save vertical space. You can read about why this can be user-hostile in the linked articles from the previous section.

I was able to identify four patterns for collapsible interactive elements that would require aria-expanded: menus, navigation, tree views and combo box.

Navigation

Perhaps because menus and navigation behave so similar, they are often confused with one another. That’s why, in my article Menu and Navigation: The Difference, I explain how to tell them apart. What they do have in common, however, is that when the content becomes extensive, so-called fly-out menus are used to show and hide content:

<nav aria-labelledby="main-nav">
	<span hidden id="main-nav">Main</span>
	<ul>
		<li><a href="…">Home</a></li>
		<li><a href="…">Shop</a></li>
		<li class="has-submenu">
			<a href="…" aria-expanded="false">
				Space Bears
			</a>
			<ul>
				<li><a href="…">Space Bear 6</a></li>
				<li><a href="…">Space Bear 6 Plus</a></li>
			</ul>
		</li>
		<li><a href="…">Mars Cars</a></li>
		<li><a href="…">Contact</a></li>
	</ul>
</nav>

In this slightly altered W3C example of a navigation we can see progressive enhancement in action:

• If CSS and JavaScript fail to load, this navigation would still work because semantic HTML was used and none of the list items are hidden.
• aria-expanded indicates that the submenu is currently collapsed.
• No additional ARIA is needed to describe the relationships between the list items and their respective parent lists, as this is communicated by the semantic HTML elements <ul> and <li>.

There is another element related to this pattern that requires the aria-expanded attribute: the so-called hamburger button!

Menu

It is very important here to distinguish whether this button is intended to reveal a navigation bar or a menu. If it is a navigation bar, aria-expanded is sufficient. If it is a menu, aria-haspopup is also required!

<button
  aria-controls="menu"
  aria-haspopup="true"
  aria-expanded="false"
  id="menu-button"
  type="button"
>
  Menu
</button>
<ul
  aria-activedescendant="mi1"
  aria-labelledby="menu-button"
  id="menu"
  role="menu"
  tabindex="-1"
>
  <li id="mi1" role="menuitem">Action 1</li>
  <li id="mi2" role="menuitem">Action 2</li>
  <li id="mi3" role="menuitem">Action 3</li>
  <li id="mi4" role="menuitem">Action 4</li>
</ul>

Depending on the scope of the menu, the following ARIA roles may also be necessary:

• aria-labelledby or aria-label: If a menubar has a visible label, the element with role menu or menubar needs to have one of these attributes set to a value that refers to the labelling element.
• aria-activedescendant: Indicates the relationship between the selected menu item and the parent element in which it is located.
• aria-checked: If it is possible to select multiple menu items, the corresponding value must be true or false.
• aria-controls: Establishes a programmatic relationship between the respective menu button and the contained menu items. As mentioned earlier, browser support is sparse, and this feature should be considered more of a nice-to-have.

A very good guide to creating progressively enhanced menus is Heydon’s article Menus & Menu Buttons. The APG explainer for the Menu Button Pattern is a good place to start if you want to get an overview of the necessary ARIA roles.

Tree view

APG distinguishes between two patterns here that are essentially the same but can vary greatly in complexity depending on the implementation:

• Tree view: “A tree view widget presents a hierarchical list.”
• Tree grid: “A tree grid widget presents a hierarchical data grid consisting of tabular information that is editable or interactive.”

In both cases, the aria-expanded attribute is required for the interactive element, which can show or hide additional elements. Here, too, other ARIA roles may be necessary depending on the implementation. This simplified example shows a possible HTML structure. It would also need a significant amount of CSS and JavaScript to convey visual information, as well as information communicated to AT:

<ul role="tree" aria-labelledby="tree-label">
  <span hidden id="tree-label">Menu</span>
  <li
    aria-expanded="false"
    aria-level="1"
    aria-posinset="1"
    aria-selected="false"
    aria-setsize="2"
    role="treeitem"
  >
    <ul role="group">
      <li
        aria-level="2"
        aria-posinset="1"
        aria-selected="false"
        aria-setsize="2"
        role="treeitem"
      >
        Content 1
      </li>
      <li
        aria-level="2"
        aria-posinset="2"
        aria-selected="false"
        aria-setsize="2"
        role="treeitem"
      >
        Content 2
      </li>
    </ul>
  </li>
</ul>

• aria-multiselectable: Necessary if more than one node can be selected.
• aria-selected or aria-checked: One of the two is required if more than one node can be selected.
• aria-labelledby or aria-label: The element with role tree has either a visible label referenced by aria-labelledby or a value specified for aria-label.
• aria-orientation: If the tree element is horizontally oriented, it has the value aria-orientation="horizontal".
• aria-level, aria-setsize and aria-posinset: These might be necessary, if “the complete set of available nodes is not present in the DOM due to dynamic loading as the user moves focus in or scrolls the tree”.
• tabindex: Depending on your implementation, you might need to implement a roving tabindex.

If you need a starting point for creating one of these components, check out Create an accessible tree view widget using ARIA by Pope Tech.

Combo box

The native <select> element can now be styled freely and also offers keyboard support, as well as robust accessibility support by default, so there should be no need to build this element yourself.

<label for="pet-select">Choose a pet:</label>

<select id="pet-select" name="pets">
  <option value="">Please choose an option:</option>
  <option value="dog">Dog</option>
  <option value="cat">Cat</option>
</select>

If it is necessary after all, the aria-expanded attribute is required here as well. In addition, aria-haspopup, aria-activedescendant, and aria-selected may also be necessary, depending on the implementation. Furthermore, aria-autocomplete and aria-labelledby or aria-label may also be required.

Make sure to give the specs of combobox role a good read before building it. Although, why go through all that trouble when the web platform provides an element that can already do all of this? 🤗

Similar but different

The following patterns can also reveal content at the touch of a button. However, this isn't so much a “fold-out” as it is a “pop-up”! Instead of using aria-expanded to communicate the state of an interactive element, you would rather use aria-haspopup oder aria-modal.

Dialog (Modal)

According to APG, the dialog pattern requires the aria-modal attribute, but let me stop you right there. The native <dialog> element has had solid browser support for quite some time and is supported by assistive technologies. In addition, we now have invoker commands at our disposal, which means you could implement this pattern without using any JavaScript! Use the dialog element (reasonably) to save time and frustration and to keep your users happy.

In this example, we’re using invoker commands. If you want to play it safe, you could also add a fallback using JavaScript, in case invoker commands are not supported yet in the browser of your choice.

<button command="show-modal" commandfor="my-dialog">
	Open dialog
</button>

<dialog id="my-dialog">
	<h2>Progressive enhancement</h2>
  <p>This dialog uses no JavaScript!</p>
  <button commandfor="my-dialog" command="close">
	  Close
  </button>
</dialog>

Tabbed interfaces

Unfortunately, there is no native, JavaScript-free solution for this pattern yet, so you’ll either have to build it yourself using aria-haspopup or use a ready-made solution from a third-party provider.

Personally, I prefer the first option so you know what’s going on under the hood. A good starting point for this is Tabbed Interfaces by Heydon Pickering.

Additionally (according to the APG), other ARIA roles such as aria-controls, aria-selected, aria-orientation, aria-label, or aria-labelledby may be added, depending on how you implement it.

Tooltip

This pattern is an interesting case, as there is no specific example of it in the APG. Nevertheless, Heydon has taken on the challenge here as well and explains in Tooltips & Toggletips how to create an accessible tooltip on your own.

Alternatively, you could experiment with how the Popover API and invoker commands work together with AT to implement this pattern natively and without JavaScript:

<button command="toggle-popover" commandfor="info">
  What is two-factor authentication?
</button>

<div id="info" popover="auto" role="tooltip">
  Two-factor authentication adds a second verification step (like a code
  from your phone) when you log in.
</div>

Once again, we need very little to get a lot done! Let’s break down what’s happening here:

• command="toggle-popover": The Popover API provides to show or hide a popover, aka toggling it.
• commandfor="info": Here we’re using the Popover API to target the element with id="info" in order to connect the button with this particular element.
• popover="auto": This enables the so-called “light-dismiss”, meaning that clicking outside of the tooltip or pressing ESC will close it.
• role="tooltip": Without explicitly specifying the role, it would have a role of “group”.

Wrapping up

Originally, this article was supposed to be about expandable buttons. Then I realised it would make more sense to write specifically about the ARIA role aria-expanded. After further research, I discovered that this attribute is no longer absolutely necessary for some patterns because the web platform has evolved significantly in recent years!

Thanks to native solutions like <detail>, <summary>, and <dialog>, as well as the Popover and Invoker Commands API, it’s possible to implement many of the patterns discussed here with minimal effort and even without JavaScript.

Nevertheless, it’s very important that not only these native (and in some cases very new) solutions are thoroughly tested with assistive technology, but also those you’ve created yourself.

It’s even more important to note that the APG patterns are not suitable for production use but should be understood solely as illustrations of how to use various ARIA roles. That’s why I’ve added an alternative example to each pattern presented, in which it was implemented with progressive enhancement in mind.

Among other things, they talk about three principles, and in this article, I’m going to discuss how they can help you in your everyday life doing web accessibility work.

Manage yourself, not the outside world

“Having the emotion, but not being ruled by it.”

You already seem to be living by this principle, otherwise you wouldn't be reading this. You can't influence how your colleagues deal with the issue of accessibility, but you have decided to be here.

There are many things we have no control over: laws, recommendations, opinions, hierarchies, technologies used, brand colours, et cetera. This can be very upsetting and you might feel your voice is not heard. Don’t be discouraged and take it personally though, because even in this confined space you still get to decide how to work with these restrictions.

You might not be able to break free from the oppressive nature of the corporate world, but you can still do your best by not taking it personally and keep moving towards the goal: improving the user experience, collaborating with your colleagues and protecting your employer from a lawsuit along the way.

Does it upset you when a team lead tells you that only 1% of their users have a disability and frankly they don’t give a shit about accessibility? It did upset me, but it didn’t stop me from “killing them with kindness”. I asked them politely where this made up number came from and if they’re aware that there are roughly 7.9 million people in Germany with an official disability instead.

Everything is an opportunity, including suffering

“The obstacle is the way.”

Let's take the dreaded carousel pattern as an example: there is a insistence on using it on the home page, preferably an external ready-made solution, because it has to be done quickly. It has been decided, the customer insists it must be used and you have no influence on this decision.

You can influence by educating your colleagues about the implications. Welcome to the amusement park of pain, take a seat on the merry-go-round of the unreasonable!

The carousel pattern is not only a questionable one and will most likely not have the desired effect that you intend, it’s also very complex to implement, especially if it must be accessible. The ARIA Authoring Practices Guide explains the Carousel (Slide Show or Image Rotator) Pattern in detail, in case you want to give your developer colleagues a look behind the scenes and get their sweat glands working overtime.

If the offer must be accessible, time (and therefore money) must be invested in finding a suitable ready-made solution, adapting it or writing it yourself. Sonja Weckenmann from tollwerk has written a very detailed, excellent article on creating accessible carousels.

The article is in German but your browser of choice should be able to translate it into your preferred language.

You could also try to convince your colleagues to integrate an MVP (minimum viable product) solution that offers simple horizontal scrolling. If you break this pattern down to its essence, that's exactly what it is: a container that you navigate horizontally to access the content.

This solution can be implemented quickly and easily, and the horizontal scroll bar can even be implemented using CSS with the brand colours. Building on this progressive enhancement approach, further complexity can be added later.

What you can also do — which is my preferred solution — is re-evaluate the use of the carousel, even if it has already been decided to use the pattern. At this point, everyone involved should be aware of the many disadvantages and few advantages and be able to form their own opinion. Simplifying design with feedback is a big part of producing excellent user interfaces.

If the carousel still has to be implemented as desired, you (and your colleagues) will suffer a lot, but you will also learn an incredible amount about accessibility during the implementation of an accessible carousel.

Choose virtue over comfort

On those mornings you struggle with getting up, keep this thought in mind—I am awakening to the work of a human being. Why then am I annoyed that I am going to do what I’m made for, the very things for which I was put into this world? Or was I made for this, to snuggle under the covers and keep warm? It’s so pleasurable. Were you then made for pleasure? In short, to be coddled or to exert yourself?

— Marcus Aurelius, Meditations, 5.1

Simply put: Sometimes there are days when you wonder why you should get up and subject yourself to the stress of everyday life when you could just stay in bed. Take the previous example: Instead of fighting a losing battle and trying to talk your boss out of the carousel pattern with very good arguments, you could just do it and be done with it.

As bleak as this situation may seem, it’s okay! If you have a little breathing room, why not document the process internally, for example? If the topic comes up again, you can show in detail what had to be done and how much work was involved. You can use hard facts to demonstrate the disadvantages and how much time went into it.

Other ways to go the extra mile could include:

• You could publish a case study as part of your company blog (if there is one) and thus help others by showing that the company takes accessibility seriously.
• You can involve designers in creating images with accessibility annotations to make the process easier to understand for a non-technical audience.
• Writing good, easy-to-understand documentation is an important skill that not only increases your market value but can also greatly improve your communication skills.

I had a colleague who was very interested in the topic but didn't have the capacity to deal with it. When he asked me to give him a glimpse behind the scenes and I showed him everything that goes into the work of an accessibility practitioner, he was very surprised. Moments like these also help to raise awareness within the team and sensitise people to the topic.

Even if you only have the capacity to do one of these things, a little goes a long way. Attentive colleagues will take note and be grateful that you went the extra mile. And who knows, maybe it will even inspire them to follow your example because they realised how it makes their own work easier?

Wrapping up

If you search for them, you will find much more than just these three principles. Some may not be so easy to apply to work in the field of web accessibility, but others will.

These three principles have helped me to take several steps back and look at my work from a bird's eye view.

More often than I would like, I get too caught up in technical details and forget that I am working with many different people to ultimately enable as many people as possible to participate digitally.

If you would like to dive deeper into this non-technical topic, I highly recommend The Accessibility Operations Guidebook by Devon Persing. In it, she explains in detail how to make accessibility work more sustainable.

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.

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.

Because I have seen this pattern so often, I'm going to to use a couple of real-life examples to find out why this is the case. The examples have been edited and shortened to make them easier to understand.

I will use the code to assess what the intention for using role="presentation" might have been and what could have been done differently. In my experience, there’s only a few real use cases for this attribute value, which we will get to later in the article.

What you might read about this attribute

We will use the specifications to take a closer look at what role="presentation" does, how it is used in the wild, and what it should actually be used for.

The official specs

If you take a look at the specification, you will immediately notice the prominent note right at the beginning (emphasis ours):

In ARIA 1.1, the working group introduced none as a synonym to the presentation role, due to author confusion surrounding the intended meaning of the word "presentation" or "presentational." Many individuals erroneously consider role="presentation" to be synonymous with aria-hidden="true", and we believe role="none" conveys the actual meaning more unambiguously.

This gives us an initial indication of why this attribute might be used incorrectly.

Authors seem to understand “presentational” as “only to be seen”; not heard. This is the behaviour of aria-hidden, which hides an element in the accessibility tree so that it is no longer announced when assistive technology is used. role="presentation" only affects the role, but not an element and its content.

The intended use is when an element is used to change the look of the page but does not have all the functional, interactive, or structural relevance implied by the element type, or may be used to provide for an accessible fallback in older browsers that do not support WAI-ARIA.

Spoiler: they’re describing layout tables here, which we’ll get into later in the article.

An element whose content is completely presentational (like a spacer image, decorative graphic, or clearing element);

The first two examples sound like image elements. If it is a decorative svg element, aria-hidden="true" would make more sense. Whereas for an img element alt="" would be more appropriate for hiding it, as this makes the intention much more obvious and it comes for free with the img element.

“Clearing element” might refer to using an element to clear float behaviour, where you would use clear: both; after using float: left; or float: right;, so it wouldn’t get dragged up the flow and break the layout.

An image that is in a container with the img role and where the full text alternative is available and is marked up with aria-labelledby and (if needed) aria-describedby;

To be completely honest, I have never seen the following example in the wild, and it is much easier to implement — and for users to read — if you use the alt attribute for alternative text in an image.

In the following example, the hidden attribute is used to hide the <span> element visually. However, it’s still available in the DOM, so it can be referenced using aria-labelledby , up there in the sibling <div> element, for example.

<div role="img" aria-labelledby="image-title">
  <img src="example-image.jpg" role="presentation">
  <span id="image-title" hidden>A beautiful sunset over the ocean</span>
</div>

In the accessibility tree, in that context, the image is displayed correctly with the corresponding alternative text, but not the source URL. If you use axe-linter in development, removing role="presentation" will trigger an alarm that images need alternative text.

An element used as an additional markup "hook" for CSS [...]

This means that in CSS, you use this attribute to target an element with role="presentation", for example like this:

table[role=presentation] {
  /* Do something */
}

A layout table and/or any of its associated rows, cells, etc.

Again, we’ll get into this pattern later on.

The specification contains many more explanations and examples, which you are welcome to look at yourself. One of the most important sentences for me is this one: “[…] the presentation role causes a given element to be treated as having no role or to be removed from the accessibility tree, but does not cause the content contained within the element to be removed from the accessibility tree.”

The following example is not intended for use in production, but is only meant to illustrate that when using role="presentation", the element itself and the elements within it lose their semantic meaning, but the content is still available:

<!-- Output: One generic element containing 
two generic elements with content. -->
<ul role="presentation">
  <li> Sample Content </li>
  <li> More Sample Content </li>
</ul>

<!-- Output: Unordered list element containing two list items. -->
<ul>
  <li> Sample Content </li>
  <li> More Sample Content </li>
</ul>

The semantic HTML is still displayed in the source code, however, if you look at them in the accessibility tree, they are displayed as generic elements, so they could just as well be <div> or <span> elements.

Enough theory, let’s have a look at some real world examples!

Questionable examples

Some of these examples won’t create any real barriers for users and I consider them not nice, but more harmless. Others will cause problems, because role="presentation" has removed important semantic meaning, which can cause more issues because of nested elements.

You will quickly learn that I removed this attribute in all of my suggested fixes, as it’s just not necessary. It was also sometimes impossible for me to guess why developers used role="presentation" in the first place.

The “invisible” iframe element

<iframe src="..." title role="presentation" loading="eager" style="width: 0px; height: 0px; border: 0px; display: none;">
  <!-- More code  -->
</iframe>

This iframe element contains a single <script> element for cookie logic. The intention here was most likely to hide it from assistive technology, as the CSS code suggests.

However, the content is still available because only the semantic meaning was removed from the iframe element. In addition, a title attribute without content was used here, which is incorrect.

Instead, the desired output could be implemented as follows:

<iframe aria-hidden="true" src="..." loading="eager">
  <!-- More code  -->
</iframe>

The list with no items

<nav>
	<ul>
	  <li role="presentation">
	  	<a href="/">To homepage</a>
	  </li>
	  <!-- More code  -->
	</ul>
</nav>

Why role="presentation" is applied to a list element here is beyond me. Especially since this is a navigation element and the semantics here have to be on point. Fortunately, it can be easily fixed by removing the attribute and using aria-current="page" for the current page.

The “hidden” image

<a href="/shop" aria-label="Shop">
  <svg role="presentation">
    <title>Shopping cart</title>
    <!-- More code  -->
  </svg>
</a>

As we learned from the specification, role="presentation" only removes the semantics of an element, but not its content, so the content of the <title> element should still be available, right? As aria-label is present, an accessible name is provided by this attribute, but not the <title> element itself.

If you would remove aria-label, it would have no accessible name at all, meaning role="presentation" has completely purged the <title> element from the accessibility tree! 🤯

The goal here was probably to hide the alternative text of the <svg> element, which worked. However, there are several ways to solve this use case more cleanly, and I would do it this way:

<a href="/shop">
  <svg>
    <title>Shop</title>
    <!-- More code  -->
  </svg>
</a>

In this case, we do not need aria-label, as the alternative text of the image is used as the accessible name.

Make it semantic, then undo it

<a href="/retail">
  <p role="presentation">Search store</p>
</a>

This is an awkward solution, but it does not present any real barriers for users, as the link text is still available. The developers probably wanted to hide the <p> element semantically, which is exactly what happens here. However, it could also have been done like this:

<a href="/retail">
  Search store
</a>

Technically meh, but still working

<div role="presentation">
  <section role="presentation" aria-label="Header">
    <!-- More code  -->
  </section>
</div>

This is a very interesting case! First of all, I don't understand why you would remove the semantic meaning but still use a semantic element.

In theory, <section> would be a generic element with an aria-label, which is prohibited according to the specification, which would result in a failure of test step 4.1.2 Name, Role, Value (Level A).

But because aria-label is present, this is ignored by the browser and the element is displayed correctly in the accessibility tree. Amazing! A technically clean solution would look like this:

<div>
  <section aria-label="Header">
    <!-- More code  -->
  </section>
</div>

Adding an accessible name and then removing it

<a href="/profile">
  <div>
    <div>
      <img alt="Go to profile" role="presentation" src="...">
    </div>
  </div>
</a>

The intention is not clear to me here either, because there are some problems due to role="presentation".

The <a> element needs an accessible name, which is not available because the <img> element has no semantic meaning and the alt attribute cannot be applied to a generic element.

Fortunately, these problems can be solved by removing role="presentation"! I also removed the <div> elements because personally, I don’t like the taste of div soup.

<a href="/profile">
  <img alt="Go to profile" src="...">
</a>

The alternative text is now linked to the image, and the accessible name of the link is provided by the alternative text. This one is similar to the “hidden” image example from earlier.

The few good use cases of this attribute

There are a couple of suggestions in the specs when you could use role="presentation", but I think only a few use cases could apply: Tabbed interfaces, menu pattern and a layout table. Let’s have a closer look at a layout table, which is using a <table> element for page layout.

Thanks to modern CSS, there’s no real need to use layout tables for websites anymore! We can produce flexible and robust designs by using flexbox and / or grid. The one use case where role="presentation" might come in handy could be email templates though.

If you are forced to use layout tables for your emails, Harvard University has a great article for you on creating accessible emails. The most relevant part for this article is the following sentence (emphasis ours):

If you must use tables for layout, add the attribute role="presentation" on every table element to ensure screen readers won’t treat them as data tables.

In the W3C Tips and Tricks section for tables, they’re also very clear on the usage of layout tables (emphasis ours):

Tables should not be used for layout purposes. Use Cascading Style Sheets (CSS) for layout. If there are already layout tables present, don’t use structural elements (like <th> or <caption>) [...], and do add role="presentation" to the <table> element.

The University of Michigan keeps it more brief but same advice:

Only use tables to present tabular data, not to create a visual layout. Use CSS or styling options to handle layout.

In Screen reader heuristics for presentational tables, you’ll find some examples on how to use role="presentation" in the context of a layout table.

Wrapping up

Thanks to a detailed analysis of the specifications, we have learned what role="presentation" does and how few use cases there actually are for this attribute. We have also seen from real-life examples how misunderstood the functionality of this attribute is among developers.

The only real use cases would be tabbed interfaces, the menu pattern and email templates, but even here, one could (if possible) switch to plain text emails and avoid using role="presentation".

Many thanks to Heydon Pickering for their help checking over this article and lending us their endless accessibility wisdom.