Hi and welcome to Accessibility by Default. If you’re a returning reader, thank you so much for coming back, and if you’re a new reader, welcome in!

Our past articles have been deep dives into comboboxes, links, buttons, as well as looking into dialogs. So, seeing as we know how to create our components accessibly, I think it’s time that we have a look at actual application accessibility and what we need to think about when we put those components together to create something bigger.

What is a single page application?

A single page application (SPA) is a web application that can update the content of the page and change the URL without requiring the browser to reload the page.

Really, it will look like you’ve navigated to a new page, with the content updating and the URL changing, but it’s JavaScript that updates the content on the page and updates the URL to reflect the new location within the application.

And if you’re not really navigating away from where you currently are, but everything is changing, therein lies our first accessibility issue — how does someone using assistive technology know that everything on the page has changed without the page actually reloading?

Accessibility Considerations

Routing

Remember that links should be used to navigate and buttons should be used for actions. Just because you’re not actually loading a new page (but you sort of are), you should still use a link for navigating the user throughout the application. Even if your framework gives you a routing function that you can call from a click handler, that doesn’t mean you should turn everything into a button.

As mentioned, the content updates as well as the URL, so make sure they both reflect appropriately where the user is. If the user is on a dashboard, the URL should reflect that. Again, just because the user is (sort of) staying in the same place, that doesn’t mean that the URL should stay the same.

And if you are updating the URL, that means that the browser history should work, so the backwards and forwards buttons should behave as expected.

Remember that SPA routing should still feel like navigating to the user — even if you’re technically staying in the same place.

Focus Management

After the route changes, the question then becomes — where does the focus go?

Realistically, because the browser hasn’t reloaded the page, but has just updated the content, we need to think about the most appropriate place to move the focus to. That could be the main page heading, or the main content of the new “page” in some cases, but please don’t just move the focus around willy nilly.

We should give the user a clear starting point for the new content without unexpectedly throwing their focus somewhere else.

Page Titles

As we’re navigating around and the route is changing, as well as thinking about where the focus goes, we also need to think about the page title.

If we think of an online store scenario — we’re looking at buying some shoes, so we’re on the shoes page. We click to add them to the basket and then we want to proceed to the checkout.

When we move from the shoes page to the checkout page, we need the page title to communicate that change. If the page title is just “Josh’s Online Shop” continuously, that isn’t going to communicate very well. We need something like “Josh’s Online Shop — Shoes” or “Josh’s Online Shop — Checkout”.

This can be one of those things that’s easy to miss when you’re primarily thinking about what the page looks like. The content has changed, the URL has changed, and visually everything might look completely different, but if the page title hasn’t changed, we’re missing another important piece of information about where the user currently is.

Announcements

Now that we’re on a new “page”, the focus has moved to the most appropriate place and we’ve updated the page title, we now need to think about how we announce to the user that all of this has happened.

We must remember that just because visually the page has changed and been updated, that doesn’t mean that someone using assistive technology will know what has changed.

If I click a link to go from the Shoes page to the Checkout page, I can see that the content has changed, I can see that the URL has changed, and the page title has changed. But what does the screen reader user get told?

Ideally, they should have some indication that navigation has happened and that they’re now looking at different content. This could be through moving focus to an appropriate location, as we’ve already discussed, but there are also situations where we may need to provide an announcement to the user.

This is where things like live regions can come in handy. We can use them to communicate dynamic changes to someone using assistive technology without having to move the focus.

But this is where we need to be careful. We don’t want to announce every single change that happens on the page, because that can quickly become a lot for the user and make the application difficult to use.

The questions become — what actually needs to be communicated, who needs to know about it, and when it needs to be announced.

We’ll take a much deeper look at live regions, announcements and communicating dynamic content in a future article (SPOILER ALERT), but for now the important thing to remember is that just because something has changed on screen, that doesn’t mean everyone using your application has been told about it.

Scroll Restoration

When a user navigates from one page to another, we need to consider how far down the original page they had scrolled before they navigated and where they should go when they land on the new page.

If you consider that a user is halfway down a page and they then click a link to navigate to a new page, the route has changed and the new content has appeared. Where should the user be in the scroll?

We also need to consider what happens if they decide to navigate back to the original page. Should they be taken back to where they were before, perhaps halfway down the page where the link they clicked was, or should they be taken back to the top of the page?

This is something that sighted users will notice immediately, but to someone using assistive technology, unexpected scroll behaviour can also make the new content harder to understand and navigate. This is all a part of creating and maintaining a predictable navigation experience.

Ideally, when navigating to a new page, the user should be taken to an appropriate starting position, usually the top of the new content. When navigating back or forward, however, restoring the previous scroll position can provide a much more predictable experience, particularly when returning to a page where the user had already been browsing.

As with focus management, though, this isn’t something we should blindly apply to every navigation. The behaviour should make sense for the type of navigation that’s taking place.

Closing thoughts

As you can see, building accessible components is only one part of the job. Once those components become part of an application, that is when we need to think about what happens when the application changes around the user.

In a traditional application, the browser will handle a lot of this for us when a new page loads. In a single page application, we’re taking more responsibility for that behaviour ourselves.

And if we’re taking responsibility for it, we need to make sure we’re doing it in a way that works for everyone.

Accessibility by Default is a series where I explore practical accessibility techniques from the perspective of a frontend engineer. Rather than repeating specifications, the goal is to explain the engineering decisions and patterns that make accessible interfaces easier to build from the start.

You can find the full series on my profile

Accessibility by Default: Single Page Applications was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.

Hi, and welcome back to Accessibility by Default. If you’re new here, welcome in, and if you’re a returning reader, thank you so much for coming back. This week we’re going to be looking at the implementation of the carousel component.

Don’t implement it. Just don’t do it. It’s an accessibility nightmare and will cause more headache and frustration for you than what it’s worth.

The end.

Thanks for stopping by. See you next week!

Why are you still here? There’s nothing else, no more than that.

Ok fine, right, let’s just talk about it, because if you really really have to implement one, you’ll have to do it correctly.

What is a carousel?

A carousel is a collection of related pieces of content, often referred to as slides, that users can move through one at a time. These might contain things like images, text, cards or other content.

Users can move through the different items using controls such as previous and next buttons, pagination indicators or other interaction methods.

A carousel isn’t directly inaccessible, just a badly implemented carousel is.

When should you use it?

You shouldn’t. Don’t.

Ok, sorry, I’ll stop making that joke now.

Carousels can be useful when you have a collection of related content that you want to present in a limited amount of space. For example, you might have a set of related promotional cards or a gallery of images where displaying everything at once would take up a significant amount of space.

But just because you can put something in a carousel doesn’t mean you should.

Before reaching for a carousel, ask yourself whether hiding some of the content behind previous and next controls actually improves the experience for the user.

If the content is important, would it be better to show everything at once?

If the user needs to compare several items, would a grid or list be easier?

If the content is constantly changing, is automatic rotation actually helping the user, or is it just making things harder to follow?

A carousel should be used because it genuinely improves the user experience, not simply because someone decided that there wasn’t enough room on the page.

Accessibility considerations

Don’t automatically rotate content

I think that this is the main one when we’re looking at the accessibility behind carousels.

If the carousel is going to automatically move through the slides then you need to give the users a way to pause or stop it. I’ve seen so many carousels that automatically rotate and, to me, that’s annoying. There have been so many times that I haven’t even processed the information before it’s automatically moved on. And if the user is trying to interact with something on the current slide but then it suddenly changes, that isn’t going to be a great user experience either.

Give users control

If you must implement a carousel, then the users should be able to navigate through it manually. The previous and next controls should be keyboard accessible and they should have clear accessible names. “Previous slide” and “Next slide” are going to be much more useful to screen reader users than just using “Previous” and “Next”. Screen reader users need to have additional context for what the buttons are going to achieve.

And, if you’re going to use pagination indicators, the current slide should also be communicated to the user.

Keyboard interaction

As always, a user shouldn’t need a mouse or touchscreen to use the component.

Every interactive control within the carousel needs to be keyboard accessible, and the user should be able to move through the carousel without getting trapped inside it.

If the carousel contains links or buttons within each slide, those need to be reachable in the expected tab order too. If a slide contains multiple tabbable elements, tabbing past the last one should move focus on to the next control in the carousel, such as the “next slide” button, rather than looping back to the start of the same slide, and rather than jumping the user out to unrelated content elsewhere on the page.

Focus management

This. Now this is where the fun begins.

When the carousel slide changes, you shouldn’t start throwing the focus around willy nilly. If a user is interacting with the carousel and then we move the focus to somewhere else every time the slide changes, that experience is going to be so bad for the user.

Focus should generally remain where the user expects it to be, and changing the visible slide shouldn’t unexpectedly steal focus from the user.

Make the current slide clear

The user needs to know which slide they’re currently on, especially if you have several.

For example, if you have five slides, someone using a screen reader should be able to know that they’re currently looking at slide 2 of 5.

We also need to make sure that the content from the inactive slides isn’t being exposed in a way that makes the experience confusing. If a slide is no longer active, we need to consider whether the content should still be available to assistive technology.

This is one of those areas where adding aria-hidden="true" can cause problems. If the slide contains focusable content, we need to make sure we're not hiding something from assistive technology while still allowing keyboard users to reach it.

Don’t forget reduced motion

If the carousel uses animations or transitions when moving between slides, we should respect the user’s reduced-motion preference.

CSS gives us a way to detect this with prefers-reduced-motion, allowing us to reduce or remove animations for users who have requested less motion.

There’s not much point in making our carousel technically accessible if we’re then making someone feel like they’re on a fairground ride whenever the slide moves.

Touch and swipe

A lot of carousels rely on swiping on mobile devices, but we shouldn’t make that the only way to navigate them.

Touch users should still have access to clear controls, and any swipe interaction should work alongside the other methods of navigation rather than replacing them.

Something to keep in mind is the conflict between swipe gestures and screen reader navigation. Both VoiceOver and TalkBack use swipe gestures to move between elements on a page, which can clash with a carousel’s own swipe to change slide behaviour. It’s usually best to provide visible on-screen buttons as an alternative, and make sure they’re not too small or easily missed because if users can’t find them, they can’t use them.

Final Thoughts

Carousels aren’t inherently inaccessible. They can be made accessible, but they do introduce a lot of additional things to think about that you might not need to think about if you were to use something else like a list, a grid or just showing all of the content.

So, before you start building one, just stop and ask yourself whether you actually need it and whether the trauma is going to be worth it.

If you do, then make sure you’re thinking about how it works for everyone, not just how it looks when someone clicks through it with a mouse.

And if you don’t need to use one?

Smile and be happy.

Accessibility by Default is a series where I explore practical accessibility techniques from the perspective of a frontend engineer. Rather than repeating specifications, the goal is to explain the engineering decisions and patterns that make accessible interfaces easier to build from the start.

You can find the full series on my profile

Accessibility by Default: Carousels was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.

Hi, and welcome back to Accessibility by Default. If you’re new here, welcome, and if you’re a returning reader, thank you so much for coming back.

If you’re a regular reader of the series, you may have noticed things have been a little quiet over the past couple of weeks. I’ve been on holiday with my family, and I decided to take a proper break — no work (only occasionally checking emails and teams), no Medium, no accessibility, and no worrying about what I should be writing next.

It was really important to me to properly switch off, spend some time with my family and come back feeling refreshed rather than heading straight towards burnout.

Now that we’re back, though, it’s time to get stuck in. This week we’re going to be looking at sliders and tooltips.

So, these are two components that, as always, look fairly simple on the surface. One is essentially a control for selecting a value, while the other is commonly used to provide additional information when a user hovers over or focuses on something.

They can seem simple, but both components can become surprisingly complex when you start looking at the accessibility behind them. There’s a lot more involved than simply making them look and behave correctly visually. We also need to consider how they function for people using assistive technology, keyboard users, touch users, and anyone else who may interact with them in a different way.

What is it?

What is a slider?

When we talk about sliders we immediately think of an input range bar. It allows you to choose a number from a predefined range, usually by dragging a handle along a track.

What is a tooltip?

A tooltip gives the user additional information about an element without requiring them to navigate away from what they’re currently doing. It’s usually displayed when an element is hovered or receives keyboard focus.

When to use it

Sliders

A slider is a useful input when a user needs to select a value from a continuous or set range, usually when the exact value isn’t the most important part of the interaction.

A common example of a slider would be selecting a volume level. A user might want the volume to be somewhere between 0 and 100, but they don’t necessarily care about the exact number (unless you’re my wife who must have the volume at a number divisible by 5). Being able to move the slider along a track can give a quick and intuitive way of making their selection.

Other examples might include things like:

• Volume controls
• Brightness
• Price ranges
• Zoom levels
• Playback position
• Adjusting image or video settings

However, there is an important point to remember here — a slider isn’t necessarily the best choice just because you have a number. If the user needs to enter an exact value such as their age, their postcode or a specific monetary amount; a text or number input is probably a better choice. Imagine asking a user to drag a slider to exactly £57.24, that isn’t going to be the best user experience.

Tooltips

Tooltips are useful when you need to provide short, contextual information about something on the page without interrupting the user’s current task.

For example, a button containing an unfamiliar icon might have a tooltip explaining what the button does. A form control might have a short piece of additional information that can help the user to understand its purpose.

But, tooltips aren’t a replacement for visible labels or instructions. If the information is important for the user to complete the task you shouldn’t be hiding it behind a tooltip. The same applies if the content is lengthy, interactive or if the user is required to spend significant time reading it. In those situations you’re best off going with a popover or dialog (which you can read about in my previous post)

Accessibility considerations

Sliders

As this is what I say with all of my component deep dives — if you can use native elements, then you should. When you consider how much <input type=”range”> actually gives you

• A recognised form control
• A semantic role
• Keyboard interaction
• Focus behaviour
• A value that can be exposed to assistive technology
• Browser/OS accessibility integration

Remember, the less accessibility that we have to code ourselves means less opportunities for us to get it wrong

For both native and custom sliders, these are the main accessibility considerations to keep in mind

Give the slider an accessible name

As with all inputs, the input should have a label that tells the user the purpose

<label for="volume">Volume</label>
<input id="volume" type="range" min="0" max="100" value="50">

A screen reader might announce something along the lines of “Slider, 50”, but that gives the user no indication of what the slider controls. Ideally, it should be announced with its accessible name as well, for example “Volume, slider, 50”.

Make the value meaningful

For a native range input, the browser handles a lot for us. But for a custom solution we have to expose

role="slider"
aria-valuemin="0"
aria-valuemax="100"
aria-valuenow="50"

And sometimes aria-valuetext if the numerical value isn't meaningful by itself.

For example, a temperature slider might expose:

aria-valuenow="20"
aria-valuetext="20 degrees Celsius"

Although, I’d be cautious about using aria-valuetext unnecessarily when you have a numerical value that already communicates everything to the user.

Keyboard interaction

This is a big one for custom sliders.

A user shouldn’t have to use a mouse or touch screen to operate a slider.

At minimum, we need to think about:

• Arrow Up / Arrow Right → increase
• Arrow Down / Arrow Left → decrease
• Home → minimum
• End → maximum

Focus

The user should be able to focus on the slider and it should be obvious where the focus is. As always, with native control we get this built in.

With a custom component, we have to make sure that the interactive element can receive focus — usually by making the slider itself focusable with tabindex="0"

Orientation

A horizontal slider is fairly obvious as that is pretty much the standard. But once we start creating vertical sliders, that is where things start to get interesting.

A custom slider needs to communicate its orientation and the keyboard behaviour needs to be predictable. That is where aria-orientation="vertical" comes in.

This isn’t just about adding the attribute for the fun of it. The visual and keyboard behaviour need to agree with what we’re exposing.

Tooltips

Tooltips have a completely different set of problems.

Don’t rely on hover

I think that this is probably the biggest one when you think about the accessibility considerations surrounding this component. If the tooltip only appears when the mouse hovers over it, then people who use keyboard navigation may never see it.

Anything that triggers a tooltip via hover should also make it available when the associated element gets focus as well.

That gives us:

Mouse: hover = tooltip
Keyboard: focus = tooltip

Don’t use title as your tooltip implementation

<button title="Delete item">

The browser may display a native tooltip, but we have very little control over its behaviour or consistency.

We can’t reliably control things like:

• How long it stays visible
• How it looks
• How it behaves on touch devices
• How it behaves with keyboard interaction
• Whether its content is exposed in the way we actually need

Remember, title shouldn’t be used as a replacement for a proper accessible name or description

Make the relationship between the element and tooltip clear

If the tooltip provides additional information about an element, assistive technology needs a relationship between the two.

This is when we use aria-describedby

<button aria-describedby="tooltip">
  Delete
</button>
<div id="tooltip" role="tooltip">
  Permanently deletes this item
</div>

Now the tooltip can provide additional information about the button rather than becoming the button’s name.

Keyboard dismissal

A tooltip shouldn’t trap the user or require them to perform some awkward interaction to get rid of it.

For a tooltip triggered by focus, moving focus away should cause it to disappear.

For hover-triggered tooltips, the user should be able to move the pointer between the trigger and tooltip where appropriate without the tooltip vanishing immediately.

Timing

Tooltips need to remain visible for long enough for the user to actually read them.

We shouldn’t make them disappear the instant the pointer moves slightly away from the trigger, particularly if the tooltip itself needs to be reached with the pointer.

We also need to consider users who may need more time to read or interact with the content.

Touch and mobile

Hover isn’t really an interaction available on a touchscreen in the same way it is with a mouse.

If the information contained within a tooltip is important, we shouldn’t rely on hover as the only way of accessing it. We need to consider how the same information will be made available to someone using a touch device.

Final Thoughts

Sliders and tooltips are very different components, but they share the same accessibility lesson: the visual component isn’t the whole component.

A slider isn’t accessible because it looks like a slider.

A tooltip isn’t accessible because it appears when you hover.

We need to consider semantics, interaction, keyboard access, focus, assistive technology and the actual information being communicated.

I know that this is basically the philosophy of the series, but I think that it’s worth repeating. Whether you’re building a slider, a tooltip, or any other component, accessibility isn’t something that should be added once the component is finished. The way the component is named, focused, operated and communicated to assistive technology is part of the component itself.

Accessibility by Default is a series where I explore practical accessibility techniques from the perspective of a frontend engineer. Rather than repeating specifications, the goal is to explain the engineering decisions and patterns that make accessible interfaces easier to build from the start.

You can find the full series on my profile

Accessibility by Default: Sliders and Tooltips was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.

Hi, and welcome back to Accessibility by Default. If you’re new here, welcome! If you’re a returning reader, thank you so much for coming back.

This week, we’re going to look into comboboxes. I feel that, on the surface, these components can appear very simple, but when you actually start to examine the functionality and accessibility behind them, it can become quite complicated.

What is it?

So, what do we mean by a combobox?

A combo box is a bit like if an input box and a select box had a baby, and then that baby was babysat by an accordion because it takes bits and pieces of all three of those components and puts them into one.

It has the look of an input, the selection behaviour of a select, and some of the disclosure and state concepts you see in an accordion.

At its simplest, a combobox is an input associated with a popup containing possible values. That popup might contain suggestions that change as the user types, or it might contain a predefined set of values that the user can choose from.

When to use it?

The main use of these components is to improve the user experience by allowing users to type into the input while the space below populates with relevant, selectable options.

A good use case for this component is when a user needs to select their country from a large list. Rather than making them scroll through a huge list of countries, they can start typing, and the combobox can filter the available options to show relevant suggestions. This is an example of a combobox with list autocomplete, where the suggestions change based on what the user types.

Comboboxes can also be useful when users are allowed to enter their own value, but suggestions are provided to help them get there more quickly. Search fields are a good example of this.

Comboboxes should be used to solve a real problem. If the user simply needs to select one value from a small, predictable list, a native <select> may be a much better option.

We should also understand the difference between a combobox and a filterable dropdown. Both components can look similar, but each has its own purpose. A combobox allows the user to enter a value while providing suggestions or options through a popup. A filterable list is primarily used for narrowing down an existing set of options, rather than allowing the user to enter an arbitrary value. Before trying to build and implement a combobox, think about what the user is trying to do.

Accessibility Considerations

When we look at the accessibility behind comboboxes, there are some similarities to accordions and disclosure that we’ve spoken about in my tabs, accordions and disclosures article, mostly around opening and closing the popup. But a combobox does have its own interaction and accessibility requirements.

Aria roles

Initially, your input should have role="combobox" and aria-expanded="false". When the popup containing the suggestions is opened, aria-expanded should change to true.

As with all input boxes for proper accessibility, it should have an associated label with it (check out my form controls article here). And then we have aria-autocomplete, which should match the autocomplete behaviour of your combobox.

There are four possible values for the aria-autocomplete:

• None — the popup contains options, but what appears doesn’t change based on what the user types
• List — the popup presents a list of suggestions that correspond to what the user has typed
• Inline — the component provides an inline completion for the value the user is entering
• Both — You get filtered suggestions and the inline completion.

These values describe different types of combobox functionality, so you need to make sure that the value matches the behaviour your component actually provides.

aria-activedescendant identifies which option is currently active while focus remains on the combobox input. This allows users to move through the suggestions with the arrow keys without actually moving the DOM focus into the listbox.

The popup itself should have an appropriate role. For the example we’re looking at, that’s role="listbox", with each suggestion represented by an option.

The currently active option and the selected option aren’t necessarily the same thing. aria-activedescendant identifies the option currently being navigated to, while aria-selected communicates selection state where the pattern requires it.

Here’s a simplified example:

<label for="country">Country</label>
<div class="combobox">
  <input
    id="country"
    type="text"
    role="combobox"
    aria-expanded="false"
    aria-controls="country-options"
    aria-autocomplete="list"
    />
  <ul id="country-options" role="listbox" hidden>
    <li
      id="country-option-1"
      role="option"
      aria-selected="false"
      >
      Canada
    </li>
    <li
      id="country-option-2"
      role="option"
      aria-selected="false"
      >
      Cambodia
    </li>
    <li
      id="country-option-3"
      role="option"
      aria-selected="false"
      >
      Cameroon
    </li>
  </ul>
</div>

In your JavaScript, you need a state mechanism that will keep the attributes in sync. When the user focuses on the input and starts to type, the script should toggle the aria-expanded to true, remove the hidden attribute from the listbox, and then change the aria-activedescendant to match the option index the user uses the arrow keys to navigate to. Then, when they blur or press the escape key, it will revert them so that aria-expanded is false, listbox receives hidden again, and aria-activedescendant is cleared.

Remember that aria-controls should reference the popup that the combobox controls. It is valid for the referenced element to be hidden when the combobox is collapsed. A listbox is the default popup type for a combobox, so aria-haspopup="listbox" is implied and doesn't need to be added in this example. If you were using a different popup type, such as a grid, tree, or dialog, then aria-haspopup should identify that type.

Keyboard interactions

This is where a combobox can become more complicated than a normal input. When the user is focused on the combobox, the down arrow can open the popup and move the active option to the first option in the dropdown, and the up arrow can be used to navigate to the last option in the dropdown. Once the user is navigating the list of options the up arrow and down arrow should move between options, and enter will accept the currently active option. If the user presses Escape, then the popup should be closed (if it is open). When an autocomplete suggestion is active, Enter will accept that suggestion and update the value of the combobox.

The main thing to remember here is that behaviour can vary depending on the type of combobox you’re implementing, but keyboard interaction should be predictable and consistent.

Focus management

Focus management, in my opinion, is one of the hardest things when it comes to comboboxes. These are the things that you must remember

• Focus is initially owned by the input
• Arrow keys are used to change the active option
• aria-activedescendant is used to communicate the active option while the DOM focus remains on the input
• Focus doesn’t necessarily move into the listbox
• Closing the popup should return you to a predictable state, such as returning the user to the input box

One of the important things to understand here is the difference between DOM focus, visual focus, and selection. A user can be moving through the suggestions while the browser’s actual focus stays on the input. By using aria-activedescendant, this allows assistive technologies to understand which option is active.

This is the part where the component can look visually correct, but it can become confusing or unusable for assistive technologies if the state isn’t correct.

What happens when an option is selected?

Another thing that we need to think about is what happens when the user selects one of the options. In the simplest example, the value of the selected option becomes the value of the input, and the list of selectable options closes so that the user can continue interacting with the rest of the page.

But this isn’t always quite as straightforward because we also need to consider whether the user needs to select one of the suggested options or whether they can enter their own value. If we go back to the country example, we don’t want the user to enter something that isn’t a country, so the suggestions are there to help them find the correct option.

On the other hand, if we’re using the combobox for something like a search field, the suggestions might just be there to help the user find what they’re looking for. They should still be able to enter their own search term, even if it isn’t one of the suggestions.

This is a distinction to make when designing the component because a combobox isn’t necessarily just a fancy select box. The behaviour of the component needs to match what we’re actually asking the user to do.

And if all we need is for the user to select one value from a predefined list, we should also ask ourselves whether we need a combobox at all.

A native <select> already gives us a well-understood and accessible interaction without having to recreate all of that behaviour ourselves.

Sometimes, the most accessible solution is simply not building the complicated thing in the first place.

Announcements and dynamic updates

When a user types into the input, the suggestions can change, the popup can open or close, the active option can change, and the selected value can be updated. For someone using a screen reader, we need to make sure they have enough information to understand what is happening.

This doesn’t mean that we should announce every single change. In fact, doing that could make the experience incredibly noisy and frustrating for someone using a screen reader.

Instead, we need to make sure that the state changes are exposed correctly through the combobox pattern.

For example, if a user types Can and a list of suggestions appears, they should be able to understand that suggestions are available and then use their arrow keys to move through them. As they move through the list, the active option should be communicated to them, and when they make a selection, the updated value should be available to assistive technology.

We also need to think about situations where the suggestions are loaded dynamically. If the user types something and the component needs to make a request before displaying the results, we shouldn’t leave the user wondering whether anything is happening.

Loading, no results, and updated suggestions are all states that need to be considered as part of the component.

The thing to remember is that accessibility isn’t just about making the options available — it’s about making the state of the component understandable as it changes.

Common mistakes

I think that this is one of those components that can be very JavaScript heavy, simply because of the interactions and the amount of state that needs to be managed.

You need to update different states depending on what the user is doing with the combobox. If they’re actively typing, you need to populate the suggestions and update the popup state. If they’re navigating through the options, you need to keep the active option and aria-activedescendant in sync. You also need to make sure the keyboard interactions work as expected while keeping focus predictable.

Another common mistake is that screen readers aren’t being given enough information about what has changed.

If suggestions appear, disappear, or change without the component exposing the appropriate state, users can be left wondering what is happening. Focus can also become problematic if it unexpectedly moves to the wrong element or disappears altogether.

And the biggest one is creating and using this whole element when you don’t need to.

If you have a selection of 20 different known and predictable values, you probably don’t need a whole combobox implementation. You could probably get away with using a native <select> with those options.

However, if you’ve got a list of over 100 countries to choose from, I’d help the user out by allowing them to narrow down their selection by using a combobox.

Key takeaways

My key takeaway from this component is that you need to keep track of all of the different states and interactions to make sure that the user doesn’t get lost while using the component, regardless of whether they’re using a keyboard or a mouse.

I also think that one of the big things to remember is that a combobox might look like a single component, but there are several moving parts underneath. You have the input, the popup, the options, the filtering, the focus management, and the interactions.

Think of it like a jigsaw.

Each piece might be straightforward, but the accessibility problems appear when you try to make all of those pieces work together.

And before you build one, ask yourself whether you actually need one. If a native control already gives you the behaviour you need, use it.

References

WAI-ARIA Authoring Practices Guide — Combobox Pattern

MDN — ARIA: combobox role

MDN — ARIA: listbox role

Accessibility by Default is a series where I explore practical accessibility techniques from the perspective of a frontend engineer. Rather than repeating specifications, the goal is to explain the engineering decisions and patterns that make accessible interfaces easier to build from the start.

You can find the full series on my profile

Accessibility by Default: Comboboxes was originally published in Design Systems Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.

Hi and welcome back to Accessibility by Default. This week we’re looking at three components that are usually grouped together because they all show and hide content: tabs, accordions and disclosures.

Although they all reveal and hide content, these components aren’t interchangeable. Each has a specific purpose, and choosing the right one changes how users navigate your content and what they expect when interacting with it.

What are tabs, accordions and disclosures?

Tabs

Tabs are used to switch between related sections of content so only one panel is visible at a time. Usually you’ll have a navigation panel at the top of the section and depending on which you choose will show the relevant information. These could be used if you visit an online store you may have a tab for description, a tab for reviews and a tab for related products.

Accordion

Accordions are comprised of a vertically stacked list of sections that can be expanded and collapsed. You have a header section which is a button to trigger the expand or collapse of the hidden information. Depending on the implementation it could be configured so that when one section expands it’ll collapse all of the others or it could be configured so that all sections can be open at the same time. These are great if you have a long list of FAQs

Disclosures

In my opinion these are the simplest of the three. You have one control, one section of hidden content, and you toggle it open or closed. This to me is like having a single section of an accordion as opposed to multiple sections. These can be used if you only have one piece of hidden information such as “Show advanced options”

When should you use each?

So now that we know what each component is let’s look at the different use cases for them because as I said before these aren’t interchangeable.

Tabs

• best for small number of equal sections
• avoid when there are large amounts of content

Accordions

• best for independent expandable sections
• avoid when users want to compare information side by side

Disclosure

• best for optional supporting information
• avoid using this for primary page content

Tabs work well when users are switching between related information or want to compare the different information. Accordions should be used when users only care about one section that is independent from the rest (but the information can still be, somewhat, related). Disclosure is ideal when its not information that users need to see all of the time.

One of the biggest accessibility mistakes isn’t forgetting an aria attribute (but please don’t do that) it’s choosing the wrong component.

A good rule of thumb is to ask yourself a simple question:

Can users benefit from seeing more than one section at once?

• If yes, consider an accordion.
• If no, tabs may be the better choice.
• If it’s only a single optional piece of information, use disclosure.

Accessibility considerations

Tabs

So when we’re looking at the accessibility side of tabs we need look at the roles of each different part. The element that is the tab component container should have role=”tablist”, each element that is a tab should have role=”tab” and the section that contains the hidden content should have role=”tabpanel”. Now that everything has a role let’s look at the aria side. Each element that has a role=”tab” should also have an aria-controls which will refer to the tabpanel component, the active tab should have aria-selected=”true” and the non-selected should aria-selected=”false”. Each element with role=”tabpanel” should have aria-labelledby which refers to the associated tab. And finally, depending on the orientation of the tablist, if it is vertical it should have aria-orientation=”vertical” (the default is horizontal so no need if that is your orientation).

Now, those are just the roles and arias needed but there are other accessibility considerations such as the left and right arrows should move to either the previous tab or the next tab. Space or enter should activate the tab that you’re currently on. Those are the mandatory interactions but there are also some optional ones; home and end should move to either the first or last tab, delete should close the current tab and set focus to the following tab

<div role="tablist" aria-label="Product information">
  <button
    id="tab-description"
    role="tab"
    aria-selected="true"
    aria-controls="panel-description">
    Description
  </button>

  <button
    id="tab-reviews"
    role="tab"
    aria-selected="false"
    aria-controls="panel-reviews">
    Reviews
  </button>

  <button
    id="tab-related"
    role="tab"
    aria-selected="false"
    aria-controls="panel-related">
    Related Products
  </button>
</div>

<div
  id="panel-description"
  role="tabpanel"
  aria-labelledby="tab-description">
  <p>This is the description panel.</p>
</div>

<div
  id="panel-reviews"
  role="tabpanel"
  aria-labelledby="tab-reviews"
  hidden>
  <p>This is the reviews panel.</p>
</div>

<div
  id="panel-related"
  role="tabpanel"
  aria-labelledby="tab-related"
  hidden>
  <p>This is the related products panel.</p>
</div>

Accordion

After that exhaustive list on tabs, thankfully the accordion pattern isn’t as big. For roles and arias you need the title of each header should be contained in an element with role=”button”, if the associated panel is visible the header button should have aria-expanded=”true” otherwise it should be set to “false”, the button element should have aria-controls set to the ID of the element containing the accordion panel content.

And in terms of keyboard interaction, space / enter should active the accordion section to either show or hide the associated content, tab should move to the next focusable element and shift + tab should take you to the previous focusable element.

<h2>
  <button
    aria-expanded="false"
    aria-controls="faq-1"
    id="faq-button-1">
    What is your returns policy?
  </button>
</h2>

<div
  id="faq-1"
  role="region"
  aria-labelledby="faq-button-1"
  hidden>
  <p>
    You can return any item within 30 days of purchase.
  </p>
</div>

Disclosure

Unlike tabs, disclosure already has a native HTML implementation using <details> and <summary>. This gives us much of the accessibility behaviour for free, making it my preferred approach whenever it meets the design requirements. For roles and states, the element that shows and hides should have a role=”button” and when the content is visible it should have aria-expanded=”true” otherwise it should be aria-expanded=”false” and optionally the element with role button has a value specified for aria-controls that refers to the element that contains all the content that is shown or hidden. For keyboard interaction it should expand / collapse using either space or enter.

If you are using native <details> and <summary>, you do not need to manually add role="button" or aria-expanded. The browser's user agent stylesheet and accessibility tree handle the toggle semantics and expansion state natively out of the box.

If you’re building a custom disclosure (e.g., using a <div> or a <button> controlling an external panel), then you need aria-expanded.

<details>
  <summary>Show advanced options</summary>

  <p>
    These settings are intended for advanced users and should only
    be changed if you understand their impact.
  </p>
</details>

The great thing about using <details> and <summary> is the built-in accessibility that comes with it, because its using the native HTML.

Common mistakes

These are the most common mistakes that i see people make when implementing these components

• Using tabs for unrelated content
• Making the accordion headers not focusable (remember role=”button”)
• Hiding the content visually but keyboard users are still able to access it
• Using accordions for everything

Key takeaways

These are my key takeaways for these components. Remember to use the component based on your need not just for styling options. Use native HTML where possible as you get the accessibility for free. Don’t forget about keyboard support and interaction and communicate aria when required

Accessibility by Default is a series where I explore practical accessibility techniques from the perspective of a frontend engineer. Rather than repeating specifications, the goal is to explain the engineering decisions and patterns that make accessible interfaces easier to build from the start.

You can find the full series on my profile

Hi, and welcome to Accessibility by Default. If you’re new, this series is all about building web components with accessibility in mind from the very beginning — understanding what native HTML gives us for free, and where we need to add a little extra ourselves. If you’re a returning reader, welcome back!

This week we’re looking at dialogs, and to be honest this is probably the topic that I’ve debated more than any throughout my career. I’ve had many, many conversations with many, many people who say, “Dialogs aren’t accessible,” but I personally don’t think that’s true.

Poorly implemented dialogs aren’t accessible. Well-implemented dialogs can be.

I often see teams remove dialogs altogether in favour of navigating users to an entirely new page because it feels like the “accessible” option. In reality, that can introduce unnecessary friction by taking users away from the task they were in the middle of just to display a small amount of related information, before expecting them to navigate all the way back again.

I’ve also seen dialogs replaced with accordions. Sometimes that’s the right decision, but sometimes it simply means exposing far more content on the page than users actually need which can, in turn, make the page looked cluttered. A dialog can allow that additional information to remain hidden until it’s requested.

Like every component we’ve looked at in this series, dialogs aren’t inherently accessible or inaccessible. The difference comes down to how they’re built.

What is a dialog?

Sorry, I may have jumped the gun slightly there by going straight into dialog accessibility before actually explaining what a dialog is.

A dialog is a component that displays additional information or requests an action from the user without navigating them away from the current page. Dialogs are usually triggered by an action on the page, such as clicking a button or interacting with a control.

Once triggered, the dialog appears above the existing page content and temporarily becomes the focus of the user’s attention.

There are two common dialog patterns we need to understand:

• Dialog — used for displaying additional information or collecting input from a user.
• Alert dialog — used for important messages that require the user’s attention before continuing.

Dialogs can also have different behaviours:

• Modal dialogs prevent interaction with the rest of the page until the dialog is closed.
• Non-modal dialogs allow users to continue interacting with the rest of the application.

A dialog might be used for many different reasons. This could be editing information, displaying additional details, or allowing a user to complete a task without leaving the current page.

A common example is an enterprise application such as a CMS system. A database record might contain many fields:

• ID
• First name
• Last name
• Phone number
• Address
• Postcode
• Country
• Additional metadata

However, the purpose of a user interface isn’t always to expose every available piece of data.

Displaying every field in a table would quickly become overwhelming and make scanning difficult. Instead, the table might display the information users need most frequently, such as the ID, name and phone number, with an action allowing the user to open a dialog containing the additional information when required.

This allows users to quickly scan the information they need while still providing access to the full record when requested.

<button>
    View information for Josh Allan
</button>

Accessibility isn’t about showing everything to everyone at all times. It’s about making sure users can access the information they need in a way that matches their task.

Modal dialogs

A modal dialog is a dialog that temporarily prevents interaction with the rest of the page until the user has completed an action or closed the dialog.

When a modal opens, the user’s focus is moved away from the page and into the dialog. While the dialog is open, users should not be able to interact with the content behind it.

Common examples include:

• confirmation messages
• login forms
• editing details
• checkout steps
• destructive actions

For example:

“Are you sure you want to delete this customer?”

This isn’t something where we want the user accidentally continuing to interact with the page behind it. The modal creates a temporary interruption where the user must make a decision before continuing.

Alert dialogs

So if a modal dialog requires a user’s attention, what makes it different from an alert dialog?

In reality, they can overlap.

A modal describes how a dialog behaves. An alert dialog describes the importance and purpose of the information being presented. An alert dialog intentionally interrupts the user’s workflow because the information requires immediate attention.

Common examples include:

• a critical error that prevents the user from continuing
• a warning about an action’s consequences
• a security-related message
• a payment failure

For example:

“Your session has expired. Please sign in again to continue.”

or:

“Your payment could not be processed. Please update your payment method before placing your order.”

These are different from a standard dialog where the user has intentionally requested more information.

For example:

Dialog

• Use case: Viewing customer details
• Purpose: Provide additional information.
• Use case: Editing profile details
• Purpose: Allow user input.

Alert dialog

• Use case: Payment failed
• Purpose: Require immediate attention.
• Use case: Session expired
• Purpose: Inform the user they must act before continuing.

A common mistake is using alert dialogs for every message because they feel like the more accessible option.

However, alert dialogs are designed to interrupt the user. Overusing them can create a frustrating experience.

Native HTML dialogs

As with every component we’ve looked at throughout this series, the first question should always be:

“Does the platform already provide this behaviour?”

Modern browsers provide the native <dialog> element.

<dialog>
  <h2>
  Customer details
  </h2>
  <p>
    Additional customer information.
  </p>
</dialog>

The native element provides many behaviours developers often recreate manually, including modal behaviour through:

dialog.showModal();

and closing through:

dialog.close();

That doesn’t mean accessibility is automatically solved. You still need to consider accessible names, focus management and the content inside the dialog.

However, starting with native HTML gives you a much stronger foundation.

The good thing about using

All of these are things to think about when implementing a custom dialog solution, but remember that native HTML gives you much of this for free out of the box.

Main accessibility points

As I mentioned earlier, many conversations I’ve had about dialogs are around whether they are accessible. The important thing is understanding the behaviours that need to exist.

The key areas are:

• Opening a dialog
• Focus trapping
• Closing a dialog
• Returning focus
• Background inertness
• Announcing dialogs

I’m aware that that does sound like a lot of different things to keep track of but once you read through, they do sound pretty obvious.

Opening a dialog

When a dialog is triggered by an action on the page, focus should move inside the dialog.

The exact location depends on the purpose of the dialog.

For example:

• A form dialog may move focus to the first input.
• An information dialog may move focus to the heading.
• A destructive confirmation may move focus to the least destructive action.

There is no single correct answer for every dialog. The important part is that focus moves into the dialog and the user immediately understands what has opened.

Focus trapping

Once focus has moved into a modal dialog, users should not be able to accidentally navigate behind it.

This is known as focus trapping.

Keyboard users and assistive technology users should be able to move between the controls inside the dialog, but pressing Tab at the final focusable element should return them to the first focusable element.

I’ve covered a simplified focus trap implementation in my first accessibility article.

// Note: This is a simplified conceptual model to demonstrate the mechanics. 
// In production architecture, use a battle-tested primitive (like Radix or 
// React Aria) 
// to handle edge cases like shadow DOM, hidden elements, and Safari bugs.

/**
 * Returns a list of elements within the specified element that can be focused
 * @param {HTMLElement} containerElement Parent element to search inside
 * @return {NodeList} The focusable elements within containerElement
 */
const getFocusableElements = (containerElement) => {
  return containerElement.querySelectorAll(
    `a[href], area[href], input:not([disabled]),
    select:not([disabled]), textarea:not([disabled]),
    button:not([disabled]), [tabindex="0"]`,
  );
};

// Focus the first focusable element if it exists
if (focusableElements.length > 0) {
  focusableElements[0].focus();
}

/**
 * Handles tab key event with given focusable elements
 * to keep focus within the modal.
 */
const handleTabKey = (event, activeElement, focusableElements) => {
  if (event.key !== 'Tab') return;
  if (focusableElements.length < 2) {
    event.preventDefault();
    return;
  }
  if (event.shiftKey && activeElement === focusableElements[0]) {
    event.preventDefault();
    focusableElements[focusableElements.length - 1].focus();
  } else if (
    !event.shiftKey &&
    activeElement === focusableElements[focusableElements.length - 1]
  ) {
    event.preventDefault();
    focusableElements[0].focus();
  }
};

The important concept is:

• Focus enters the dialog.
• Focus stays within the dialog.
• Focus returns when the dialog closes.

If you’re using the native <dialog> element with showModal(), this is handled for you automatically.

Closing a dialog

Dialogs should provide clear ways for users to close them.

Common methods include:

• A close button.
• Pressing Escape.
• An optional backdrop click.

Backdrop clicking should be used carefully. Some dialogs contain important information or forms where accidental dismissal could cause frustration.

When a dialog closes, focus should return to the element that opened it.

If a user clicked a button to open a dialog, that button should regain focus once the dialog closes.

This allows users to continue exactly where they left off.

I still remember the first custom modal I built. During testing, our tester repeatedly pressed Enter to open the modal, checked that focus moved to the first focusable element (the close button in this case), activated it, then verified that focus returned to the original trigger. It felt repetitive at the time, but it’s exactly the kind of behaviour that’s easy to miss when you’re only testing with a mouse.

Background inertness (inert vs aria-hidden)

One of the most common mistakes with modal dialogs is only thinking about what users can see.

A modal might visually appear above the page, but if the content behind it is still available to keyboard users, then the experience is broken.

For example:

<div class="modal">
  <h2>
    Delete customer?
  </h2>

  <button>
    Cancel
  </button>

  <button>
    Delete
  </button>
</div>

Visually, this may look like a modal.

However, a keyboard user can still potentially press Tab and move through the page behind the dialog.

This creates confusion because the user has entered a modal state visually, but the browser still allows interaction with the content underneath.

This is where the inert attribute becomes useful.

<main inert>
  Page content
</main>

The inert attribute tells the browser that the content should not:

• receive focus
• respond to user interaction
• be exposed to assistive technology

A common older approach was using:

aria-hidden=”true”

However, these solve different problems.

aria-hidden only removes content from the accessibility tree. It does not prevent keyboard users from reaching interactive elements.

For example:

<button aria-hidden="true">
  Submit
</button>

The button may still be focusable even though assistive technology cannot announce it.

For modal dialogs, the goal is not just hiding content from screen readers. The goal is preventing interaction with the rest of the page.

This is why inert is the better solution.

Native <dialog> opened via showModal() also makes the rest of the page inert automatically — you don't need to add this yourself.

Announcing dialogs

Moving focus into a dialog is only part of the experience. Users also need to understand what has opened and why.

A dialog needs an accessible name.

The preferred approach is usually using aria-labelledby connected to a visible heading.

Example:

<dialog aria-labelledby="customer-details-title">
  <h2 id="customer-details-title">
    Customer details
  </h2>

  <p>
    Additional information about this customer.
  </p>
</dialog>

A screen reader can now announce something like:

“Customer details, dialog”

rather than simply:

“Dialog”

which provides no useful context.

If there isn’t a visible heading, you can provide a name using:

aria-label

Example:

<dialog aria-label="Delete customer">

However, visible text is generally preferred because it keeps the visual and accessible experiences aligned.

You can also provide additional context using:

aria-describedby

Example:

<dialog aria-labelledby="delete-title" aria-describedby="delete-description">

With:

<h2 id="delete-title">
  Delete customer
</h2>

<p id="delete-description">
  This action cannot be undone.
</p>

A screen reader user receives:

• the name of the dialog
• the purpose of the dialog
• any additional instructions

The goal is the same as with every accessible component:

The user should understand what they are interacting with, what state they are in, and what action they need to take.

Key takeaways

Accessible dialogs come down to a few core principles:

• Use the correct dialog pattern for the situation.
• Move focus into the dialog when it opens.
• Keep focus within modal dialogs.
• Return focus when the dialog closes.
• Prevent background interaction.
• Provide a clear accessible name.
• Prefer native HTML where possible.

Like every component we’ve looked at in this series, accessibility is rarely about adding more complexity. Often, it is about understanding the behaviour users need and using the tools the platform already provides.

If there’s one thing I hope you take away from this article, it’s that dialogs aren’t inaccessible — they’re just one of the easiest components to implement incorrectly. Understanding focus management, user context and native browser behaviour will get you much further than trying to avoid dialogs altogether.

Accessibility by Default is a series where I explore practical accessibility techniques from the perspective of a frontend engineer. Rather than repeating specifications, the goal is to explain the engineering decisions and patterns that make accessible interfaces easier to build from the start.

You can find the full series on my profile

Hi! If this is your first time here welcome! This is a series in which we dive into the accessibility side of frontend development from an engineers perspective. We’re working through common UI components to understand the building blocks that make them accessible from the start. And, if you’re a returning reader, welcome back! This week we’re going to be looking into form controls.

Forms are one of the most common places that users can interact with a website, from contact details to orders but they can also be one of the easiest places that can accidentally introduce accessibility barriers.

A form that looks visually correct can still be difficult or impossible to use for different types of assistive technology such as screen readers, keyboard navigation, voice control software or cognitive accessibility tools.

The foundation of accessible forms is simple:

Every control needs a clear purpose, a clear name, and a clear state.

In this article we’ll cover the building blocks of accessible form controls:

• text inputs
• labels
• checkboxes
• radio groups
• switches
• helper text
• required fields
• grouping related controls with fieldset and legend

Text Inputs

One major flag that causes an accessibility issue is a text input without a label.

<input type="text" />

Always provide an accessible name

The most common solution is a visible <label>.

<label for="email">
  Email address
</label>
<input id="email" type="email" />

The relationship is created through the matching attributes:

• label for
• matching input id

Now assistive technology can announce:

“Email address”

Avoid placeholder-only labels

A common pattern is:

<input placeholder="Email address" />

This is not a replacement for a label.

Problems:

• disappears when the user starts typing
• lower contrast
• users with cognitive difficulties may forget the purpose
• screen reader support varies

Use placeholders for examples:

<label for="postcode">
 Postcode
</label>
<input id="postcode" placeholder="Example: SR1 1AA" />

Another pattern that is accessible for inputs and other form controls is to nest the input within the label as this gives implicit association between the elements.

<label class="field-container">
  <span class="label-text">
    Email Address
  </span>
  <span class="hint">
    We will never share your email.
  </span> <input type="email" name="email">
</label>

<label> Username <input type="text" name="username"> </label>

While nesting is perfectly valid HTML, I generally prefer explicit for/id associations. As labels become more complex—with helper text, icons, or additional markup—the relationship is easier to understand, maintain and debug when it is explicit.

Checkboxes

Checkboxes represent independent choices.

<label>
  <input type="checkbox" />
  Subscribe to newsletter
</label>

The label wraps the input, creating the relationship automatically.

Alternatively:

<input id="terms" type="checkbox" />
<label for="terms">
  I agree to the terms and conditions
</label>

Checkbox groups

When multiple checkboxes belong together, provide a group name.

<fieldset>
  <legend>
    Preferred contact methods
  </legend>

  <label>
    <input type="checkbox" />
      Email
    </label>

  <label>
    <input type="checkbox" />
      Phone
  </label>
</fieldset>

With this pattern the inputs are grouped together using <fieldset> the <legend> acts as a label for the group. The user will now hear “Preferred contact methods, group” before reaching the checkboxes.

Radio Groups

Radio buttons represent a single choice from multiple options.

<fieldset>
  <legend>
    Account type
  </legend>

  <label>
    <input type="radio" name="account" value="personal" />
    Personal
   </label>

  <label>
    <input type="radio" name="account" value="business" />
    Business
   </label>
</fieldset>

The important parts of this pattern are

• Same name: each of the inputs use the same name so this tells the browser that these controls belong together
• Fieldset and legend: we’re using the fieldset and legend here again to group the inputs and give the group an accessible label

Switches

Switches are intended for toggling a setting or preference. Common examples include:

• Enabling notifications
• Switching between light and dark mode
• Turning automatic updates on or off

A switch represents a binary or boolean state — on/off or true/false.

<button
  id="notifications-switch"
  role="switch"
  aria-checked="true"
>
  Notifications
</button>

const switchElement = document.getElementById("notifications-switch");

switchElement.addEventListener("click", () => {
  const isChecked =
    switchElement.getAttribute("aria-checked") === "true";
  switchElement.setAttribute(
    "aria-checked",
    String(!isChecked)
  );
});

The important parts are:

• Accessible name → Notifications
• Role → switch
• State → aria-checked="true" or aria-checked="false"

A screen reader should announce:

“Notifications, switch, on”

or

“Notifications, switch, off”

Don’t use switches for actions

A switch changes the state of something.

A button performs an action.

• “Save changes” as a switch is incorrect
• “Enable notifications” as a switch is correct

Helper Text

Helper text provides additional information:

Examples:

• formatting requirements
• password rules
• explanations

<label for="password">
  Password
</label>
<input id="password" aria-describedby="password-help" />
<p id="password-help">
  Must contain at least 8 characters.
</p>

aria-describedby connects the additional information.

A screen reader announces:

“Password, edit text, Must contain at least 8 characters”

Required Fields

Required fields should communicate both visually and programmatically.

Visual:

<label>
  Email address *
</label>

is not enough.

The asterisk has no meaning to assistive technology.

Use:

<input required />

and make sure the label explains that is is required:

<label>
  Email address <span aria-hidden="true">*</span>
</label>

Validation Messages

Errors should be associated with the input.

<input aria-invalid="true" aria-describedby="email-error" />
<p id="email-error">
  Enter a valid email address.
</p>

The user receives:

• what is wrong
• where it is wrong
• how to fix it

Validation should not rely on colour alone and error messages should appear at the point the error occurs, not just at the top of the page.

Grouping Controls with Fieldset and Legend

I know we’ve mentioned using fieldset and legend in the previous examples for checkboxes and for radios but fieldset and legend are often overlooked.

They are not just visual containers, they provide semantic relationships between the elements.

<fieldset>
  <legend>
    Delivery address
  </legend>

  <label>
    Street address
  </label>
  <input />

  <label>
    City
   </label>
  <input />
</fieldset>

Screen readers announce the group name before users navigate through the controls, helping provide context for the fields that follow.

Key take aways

Accessible forms have a few core principles:

• Every control has an accessible name
• Labels are always associated with inputs using either explicit (for/id) or implicit (nested) labelling
• Groups should have meaningful names and an accompanying legend
• States are communicated programmatically
• Helper text is connecting using relationships
• Errors should be associated with the input and should explain what went wrong and how to fix it

One thing you’ll probably have noticed throughout this article — and hopefully throughout this series — is just how much accessibility comes for free when we lean on native HTML. Before reaching for ARIA or custom components, ask yourself whether a native element already provides the behaviour you need. More often than not, the browser has already solved the accessibility problem for you.

Accessibility by Default is a series where I explore practical accessibility techniques from the perspective of a frontend engineer. Rather than repeating specifications, the goal is to explain the engineering decisions and patterns that make accessible interfaces easier to build from the start.

You can find the full series on my profile

Welcome back to Accessibility by Default. If this is the first post you’re reading, welcome in and be sure to check out the previous posts in the series. This series explores how we can build components with an accessibility-first approach. Accessibility shouldn’t be an afterthought; it should be considered from the very beginning of development.

Last week we looked at buttons, and one of the key principles was simple: use native HTML first. This week we’re continuing that idea with another fundamental component — links.

I know what you’re thinking: “Links are easy, it’s just an <a> tag.” But, like most things in frontend development, there’s more complexity hiding beneath the surface.

In this article, we’ll look at native links, links vs buttons, accessible link names, icon and image links, and some of the common mistakes that can make a seemingly simple component less accessible.

Native links vs everything else

As with every article in this series, if you can use a native HTML element, you probably should. Native elements already provide a huge amount of functionality and accessibility behaviour without requiring additional code.

When using a native <a> element, you get a lot of behaviour built into the browser:

Keyboard interaction

Native links are automatically keyboard accessible and follow the natural document order. Users can navigate between links using their keyboard without developers needing to manually recreate interactions or add custom event handlers.

Focus behaviour

Browsers already understand how links should receive focus and how users should interact with them. By replacing a link with a custom element, developers take responsibility for recreating that behaviour themselves.

Browser behaviour

Native links work with the features users already expect from the web. Users can open links in new tabs, copy URLs, use browser history, and understand where a link will take them before interacting with it.

Context for assistive technologies

Assistive technologies understand the difference between links and other interactive elements. A screen reader user can navigate between links, understand their purpose, and move through a page more efficiently.

Expected interaction patterns

Users have built mental models around how interfaces work. A link should take someone somewhere, while a button should perform an action. Keeping these behaviours consistent creates a predictable experience for everyone.

The more we replace native HTML with custom implementations, the more responsibility we take on ourselves. The browser has spent decades solving these problems — whenever possible, we should let it.

Links vs buttons

One of the most common accessibility mistakes in modern applications is confusing links and buttons.

They can often look identical visually, but they represent completely different interactions.

The simplest way to think about the difference is:

Links navigate. Buttons perform actions.

If something takes a user to another page, route, or location, it should usually be a link:

<a href="/settings">
  Settings
</a>

If something performs an action on the current page, it should usually be a button:

<button>
  Save changes
</button>

This distinction matters because assistive technologies communicate these elements differently, and users build expectations based on those announcements.

A screen reader user navigating through a page expects a link to take them somewhere. They expect a button to perform an action.

When we use the wrong element, we create confusion even if the component looks visually correct.

When buttons become links

A common pattern is using a button for navigation:

<button onclick="window.location='/profile'">
  View profile
</button>

Technically, this works. The user can click it and arrive at the correct page.

However, it is still the wrong semantic choice.

The browser no longer understands that this is navigation. As a result, users lose expected link behaviour such as:

• opening the link in a new tab
• copying the destination URL
• using browser history naturally
• understanding the destination before activating it

The better solution is to use the element that already represents the behaviour:

<a href="/profile">
  View profile
</a>

When links become buttons

The opposite problem is also common:

<a href="#" onclick="openModal()">
  Open settings
</a>

Again, it might work visually, but this is an action, not navigation.

The user isn’t going anywhere. They are triggering something on the current page.

This should be a button:

<button>
  Open settings
</button>

By choosing the correct element, we get the correct semantics, keyboard behaviour, and interaction patterns without needing to recreate them ourselves.

Accessible link names

Just like buttons, links need a clear accessible name.

For many links, the visible text already provides this:

<a href="/account">
  Account settings
</a>

A screen reader user will understand where the link will take them.

However, problems start when link text becomes vague:

<a href="/guide">
  Click here
</a>

or:

<a href="/article">
  Read more
</a>

These might make sense visually when surrounded by content, but they lose meaning when someone navigates through a list of links.

Imagine hearing:

“Link, click here”

“Link, click here”

“Link, read more”

There is no context about where those links go.

A better approach is to make the link text describe the destination:

<a href="/info">
  Read more about our approach
</a>

The goal is not to add extra information specifically for screen readers. The goal is to make the link meaningful for everyone.

Icon, image, and logo links

Modern applications frequently use links without visible text.

Examples include:

• logo links back to the homepage
• social media icons
• search icons
• account icons

Similar to icon-only buttons, icon-only links can cause the same issues. Visually, these can be obvious. However, without text, assistive technologies need another way to understand the purpose.

For example:

<a href="/search">
  <svg>
    …
  </svg>
</a>

Without an accessible name, a screen reader user may only hear:

“Link”

The purpose of the link has been lost. This is where techniques like alternative text or ARIA labels can help.

For example:

<a href="/search" aria-label="Search">
  <svg>
    …
  </svg>
</a>

The important point is the same as with buttons: ARIA should restore missing meaning, not replace native semantics.

Links that aren’t really links

A pattern that still appears in many codebases is using links as generic clickable elements:

<a href="#">
  Open menu
</a>

or:

<a onclick="openModal()">
  Settings
</a>

These are not really links.

They don’t navigate anywhere. They perform actions.

The problem with this approach is that developers often end up fighting against the browser:

• preventing default behaviour
• manually handling keyboard interaction
• managing focus
• recreating button behaviour

If something performs an action, use a button.

If something navigates, use a link.

Choosing the right element from the start removes a lot of unnecessary complexity (and headache further down the line!).

Opening links in new tabs

Another area where links can become confusing is opening new browser contexts.

For example:

<a href="/report" target="_blank">
  Annual report
</a>

Opening a new tab isn’t automatically wrong. There are legitimate reasons to do it.

However, unexpected changes in context can be confusing, especially for users who rely on assistive technologies.

If a link opens somewhere new, make that clear:

<a href="/report" target="_blank">
  Annual report
  <span class="sr-only">opens in new tab</span>
</a>

As you can see from this example, visually the link will read “Annual report” but for screen readers it will read “Annual report opens in a new tab”. The sr-only class visually hides the text while keeping it available to assistive technologies. The important thing is not avoiding new tabs completely. It is ensuring users understand what will happen before they activate the link.

Skip links

Skip links are a great example of how a simple native link can solve a real accessibility problem.

On many websites, the first thing in the DOM is navigation:

• company logo
• navigation menu
• search
• account controls
• other repeated content

For mouse users, this usually isn’t an issue. They can simply click where they need to go.

For keyboard users, however, this means having to navigate through the same content every time they visit a page.

A skip link provides a way to bypass that repeated content and jump directly to the main content:

<a href="#main-content">
  Skip to main content
</a>

…

<main id="main-content">
  Page content
</main>

When a keyboard user focuses this link and activates it, the browser moves focus directly to the main content.

The important thing here is that we don’t need to create a custom component or complex JavaScript solution. A native link already provides exactly the behaviour we need.

Skip links are often visually hidden until they receive focus, allowing them to stay out of the way for users who don’t need them while remaining available to keyboard users.

They are a great reminder that accessibility improvements don’t always need to be complicated. Sometimes the simplest solution is using the HTML element that already exists for the job.

The Principle: use native HTML first

Links are one of the simplest examples of where native HTML already provides the correct behaviour.

When something is navigation, use a link.

When something performs an action, use a button.

By choosing the correct element first, we get accessibility, browser behaviour, and expected interaction patterns without needing to add extra complexity.

Accessibility is not about adding more code. It’s about making better decisions earlier in the development process.

Accessibility by Default is a series where I explore practical accessibility techniques from the perspective of a frontend engineer. Rather than repeating specifications, the goal is to explain the engineering decisions and patterns that make accessible interfaces easier to build from the start.

You can find the full series on my profile

Welcome back to Accessibility by Default. In the first post, we talked about getting the foundations right — structure, semantics, keyboard support, and focus management. Now we’re going to start looking at building more practical components.

To start with, we’re going to look at buttons. Even with things that look as simple as a button — I’ve seen them go wrong! Most developers look and think, “it’s just a button, that’s all there is to it,” but they’re wrong. Buttons can be one of those deceptively simple components where accessibility issues show up very quickly if you get the fundamentals wrong. A lot of that comes down to the number of variations we end up building in real applications.

Native buttons vs everything else

When you think about a button as just a visual element with a click handler, it feels simple. But from an accessibility perspective, there’s a lot more going on:

• Keyboard support
• Focus behaviour
• Accessible name behaviour
• Interaction semantics

These are all things you get “for free” when you use a native <button> element. That’s really the key point here: native HTML already solves most of this problem for you.

Architectural Tip: Never leave a button’s default type to browser guesswork. If a native <button> lives inside a <form>, the browser defaults its type to submit. If a developer adds a click handler to execute local state changes without calling e.preventDefault(), the entire page will unexpectedly reload. Make it an engineering standard to explicitly declare <button type="button"> or <button type="submit"> every single time.

Where things start to go wrong is when developers recreate buttons using something like a <div role="button"> and then try to rebuild all of that behaviour manually. That’s not impossible—but it’s easy to miss edge cases, especially around keyboard interaction and focus management. Browsers have had decades of work put into making native controls accessible. Replacing them means taking responsibility for all of that behaviour yourself—and trust me, some of that can get lost when you’re doing it yourself!

Icon buttons and accessible names

One of the first places buttons start to get complicated in real applications is with icon-only buttons. They are everywhere:

• search buttons
• close buttons
• menu toggles
• settings icons

Visually, they make sense. The icon usually communicates intent clearly to sighted users. But for assistive technologies, this is where issues start to appear. If there is no text, there is nothing to describe what the button does. Without that, you’ll often just get something like: “button”.

That’s not a useful experience for anyone. Imagine using a screen reader to go through a page and all you hear is “button” “button” “button” with no indication of what each one does.

Where semantic HTML stops being enough

A native <button> will automatically use its text content as its accessible name:

<button type="button">Search</button>

But once you remove visible text and replace it with just an icon, that text context is lost:

<button type="button">
  <svg>…</svg>
</button>

At that point, you’ve lost the accessible name entirely, leaving the screen reader user with no context for what the button does. This is where developers usually reach for ARIA:

<button type="button" aria-label="Search">
  <svg aria-hidden="true" focusable="false">…</svg>
</button>

And this is a valid use case. The point here isn’t that ARIA is good or bad — it’s that it should be used to restore meaning that would otherwise be lost, not to replace something that should already exist.

Notice that we also explicitly added aria-hidden="true" and focusable="false" to the child <svg>. Without this, some browsers and assistive technologies will dive into the SVG subtree and read internal path data or random IDs, polluting the screen reader announcement.

The first question should always be: “can native HTML solve this problem?”

Disabled buttons (and why they’re not always harmless)

Another area that gets overlooked is disabled buttons. On the surface, disabling a button seems simple:

HTML

<button type="submit" disabled>Submit</button>

But there are a few subtle implications:

• Disabled buttons are completely removed from the browser’s tab order.
• They may not be encountered or read in the same way by assistive technologies.
• Users may not understand why the action is unavailable.

This often leads to a poor experience when a form button is disabled without explanation, the state change isn’t communicated clearly, and users don’t know what they need to fix to continue.

A disabled button isn’t always the best experience. In many cases, it’s better to allow the interaction and explain what needs to be fixed, rather than silently preventing it altogether via the native disabled attribute.

HTML

<button type="submit" aria-disabled="true">Submit</button>

Using aria-disabled="true" is a powerful compromise for form validation. It keeps the button focusable in the keyboard layout so screen reader and keyboard-only users can still locate the control and discover it exists. You can then style it to look inactive visually, communicate requirements via inline validation or helper text, and prevent the actual execution via JavaScript. The goal is not just to prevent interaction—it’s to communicate state clearly.

Toggle buttons

Buttons are not always just “do something once and done”. Sometimes they represent a persistent state. For example:

• favourite / liked
• expand / collapse
• bold / italic in text editors

In these cases, a button is no longer just an action — it’s a toggle. This is where aria-pressed becomes useful:

<button type="button" aria-pressed="true">
  Favourite
</button>

This tells assistive technologies that:

• the button holds a state
• that state can change
• what the current state is

Without this, a screen reader user just hears “button”, with no indication that it represents something persistent that can be toggled on or off.

Buttons that aren’t really buttons

A pattern you still see in older codebases (and unfortunately still in some modern ones) is using a non-interactive element and trying to “upgrade” it:

<div role="button" tabindex="0">
  Click me
</div>

This can be made to work, but it comes with immense trade-offs:

• you must manually handle keyboard interaction (listening for both Enter and Space keys)
• you must manage focus behaviour yourself
• you must ensure consistency across layout engines and devices
• you must maintain all of this manual boilerplate forever

And the most important point is that you’re reinventing something the browser already gives you for free. In almost all cases, a native button is simpler, safer, and more predictable:

<button type="button">Click me</button>

The guiding principle is simple: If it behaves like a button, use a <button>.

Buttons vs links

This is a common area of confusion, and I’ve seen it go wrong on plenty of projects. Sometimes you end up with links behaving like buttons, and buttons behaving like links.

The simplest way to think about it is:

• Buttons — Triggers an action on the current page
• Links (<a>) — Navigates the user to a new page, anchor, or route

If something takes the user to a new page or route, it should be a link:

<a href="/settings">Settings</a>

If it triggers a state change or operation on the current page, it should be a button:

<button type="button">Save changes</button>

Where things go wrong is when these roles get swapped purely for styling reasons (e.g., links styled as buttons, or buttons used for navigation). This affects more than just visuals — it changes how screen readers announce the element, shifts the expected keyboard behaviour, and breaks user mental models.

You can style either element however you like visually to match your design system, but the underlying element must reflect the actual programmatic intent.

The Principle: Use Native HTML First

The biggest takeaway from buttons is simple: start with the HTML element that already matches the behaviour you need. Native buttons provide keyboard support, focus behaviour, and interaction semantics without needing custom code. The more we replace these built-in behaviours, the more engineering responsibility we take on ourselves.

Accessibility is not about adding complexity — it’s about making the right structural decisions early.

Accessibility by Default is a series where I explore practical accessibility techniques from the perspective of a frontend engineer. Rather than repeating specifications, the goal is to explain the engineering decisions and patterns that make accessible interfaces easier to build from the start.

You can find the full series on my profile

For some developers, accessibility isn’t at the forefront when building new components, webpages or applications. Sometimes it isn’t considered until an accessibility issue is picked up in code review or later in testing.

In an ideal world, accessibility should be one of the first things you think about when looking at a new design or working through functionality. It shouldn’t be a box-ticking exercise you deal with at the end of a sprint when someone reminds you it exists.

Instead, it should be part of the engineering defaults set out by the team — something you do by default when building, so that everything is usable by as many people as possible from day one.

Most accessibility issues don’t come from edge cases. They come from incorrect foundations.

I’ve seen a handful of developers (not naming any names) who will sometimes hotfix accessibility issues on the fly, whereas if the component had been structured correctly in the first place, the issue wouldn’t exist.

Get the structure, semantics, and interaction patterns right early, and a surprising number of accessibility problems never show up in the first place.

Semantic HTML vs ARIA

This is probably one of the most misunderstood parts of accessibility, and also one of the easiest places to accidentally make things worse.

The easiest way to think about it is:

HTML gives meaning. ARIA tries to patch meaning on top.

If you can use a native HTML element, you should. When we have a bunch of different elements, why would we look at overcomplicating the built in functionality that is already there? If you consider in HTML we already have <button>, <input> and <nav>; these elements already tell assistive technologies how to behave and interact with the page.

When you start to replace them with generic elements such as <div> and then layer a bunch of ARIA roles on top, you’re basically reinventing the wheel when that behaviour already exists — and there’s a good chance that some of the key functionality will be missed.

That isn’t to say that ARIA is bad — it’s more so that it has a specific job and misusing it can cause headaches and issues down the line.

ARIA is useful when:

• You’re building something doesn’t exist in HTML
• You need to enhance meaning for assistive technologies
• You can’t achieve the behaviour with native elements

ARIA isn’t good for:

• Fixing broken HTML structure
• Replacing native elements
• Sprinkling in roles just in case

Hierarchy and Document Structure

I feel as though this is one of those areas that doesn’t get much attention, but it can easily affect everything else.

When people think about accessibility, 9 times out of 10 they jump straight into ARIA, but the structure of the page underneath is usually what can make or break the user experience.

At a basic level, a webpage isn’t just the visual layout — there’s a hierarchy that assistive technologies rely on to make sense of what is going on.

Headings are probably the simplest example of this. They’re not just for styling or making text look bigger — they create a map of the page. This map is what assistive technologies use to navigate coherently around the webpage.

The same can be applied to landmarks such as <main>, <nav> and <footer>. These elements give structure to the page and help users understand where they are in the flow of the page without needing to interpret the visual layout.

One of the most common misuses I see is when heading levels are chosen based on visual size, rather than the structure of the page. For example, jumping from an <h1> to an <h4> just because “it looks right” visually. That might not seem like a big deal, but it breaks the logical flow of the document.

A good way to think about it is:

If you took away all of the styling, would the webpage still make sense in the right order?

If the answer is no, then the structure probably needs work.

One thing I find myself doing often is turning on a screen reader and closing my eyes to navigate a page. If I can do that and understand what’s going on, and I know where I am, then we’re in a good place.

Keyboard Accessibility

If there’s one area that instantly exposes accessibility issues within a system, it’s keyboard navigation.

It can sound basic, but if something doesn’t work properly with a keyboard, it’s usually a sign that something more fundamental has been missed.

A lot of users don’t use a mouse at all, and some will switch between keyboard and assistive technologies depending on the task. So if your webpage can only be operated with a mouse, you’re effectively limiting how much of it can be used.

At a minimum, every interactive element should be reachable and usable with a keyboard. That includes buttons, links, form controls, menus, and anything custom that behaves like a control.

Native HTML elements handle this for you by default, which is another reason they’re so important. A <button> can be focused, activated with Enter or Space, and behaves consistently across browsers without any extra work. When you move away from native elements, you have to rebuild all of that yourself — and that’s where things often start to break.

One of the most common problems is interactive elements that are technically clickable, but not actually focusable or operable via keyboard. It might work fine with a mouse, but if you tab through the page and hit a dead end, that’s a problem.

It’s at this point in the development process that custom components start to show their complexity. Things like dropdowns, modals, and tabs all need to behave in a predictable way when interacted with using a keyboard, not just mouse clicks.

Focus Management

If keyboard accessibility is what lets users move around a page, focus management is what tells them where they are when things change.

This becomes especially important in more dynamic applications, where content updates without a full page reload — things like single page applications, modals, dialogs, and routing changes.

In traditional multi-page websites, focus naturally resets because the page reloads. In SPAs, that doesn’t happen — so you have to be intentional about where focus goes after a change in state.

A simple rule of thumb is:

When something significant changes in the UI, the user’s focus should usually move with it.

That might mean:

• moving focus to a newly opened modal
• shifting focus to a page heading after navigation
• returning focus to the triggering element when something closes

Modals and focus trapping

Modals are a good example of where this becomes obvious. When a modal opens, focus should move into it and stay contained within it until it is closed. If focus can escape behind the modal, users can end up interacting with content that is no longer relevant or visible.

This is usually referred to as focus trapping — keeping keyboard focus inside the modal while it is active.

While you should almost always lean on battle-tested architectural primitives (like Radix, headless UI, or React Aria) to handle focus trapping in production, understanding the raw underlying mechanics is essential for any frontend engineer:

• find all focusable elements inside the modal
• move focus to the first one
• intercept Tab and Shift + Tab to cycle within the modal

// Note: This is a simplified conceptual model to demonstrate the mechanics. 
// In production architecture, use a battle-tested primitive (like Radix or 
// React Aria) 
// to handle edge cases like shadow DOM, hidden elements, and Safari bugs.

/**
 * Returns a list of elements within the specified element that can be focused
 * @param {HTMLElement} containerElement Parent element to search inside
 * @return {NodeList} The focusable elements within containerElement
 */
const getFocusableElements = (containerElement) => {
  return containerElement.querySelectorAll(
    `a[href], area[href], input:not([disabled]),
    select:not([disabled]), textarea:not([disabled]),
    button:not([disabled]), [tabindex="0"]`,
  );
};

// Focus the first focusable element if it exists
if (focusableElements.length > 0) {
  focusableElements[0].focus();
}

/**
 * Handles tab key event with given focusable elements
 * to keep focus within the modal.
 */
const handleTabKey = (event, activeElement, focusableElements) => {
  if (event.key !== 'Tab') return;
  if (focusableElements.length < 2) {
    event.preventDefault();
    return;
  }
  if (event.shiftKey && activeElement === focusableElements[0]) {
    event.preventDefault();
    focusableElements[focusableElements.length - 1].focus();
  } else if (
    !event.shiftKey &&
    activeElement === focusableElements[focusableElements.length - 1]
  ) {
    event.preventDefault();
    focusableElements[0].focus();
  }
};

It’s not the prettiest or most “modern” implementation, but the underlying idea is what matters — keeping focus behaviour predictable inside a contained interaction.

The same idea applies to route changes in SPAs. If a user navigates to a new view but focus stays on the element that triggered the navigation, they may not realise anything has changed.

In those cases, moving focus to something meaningful — usually the main heading or primary landmark — helps re-orient the user.

Another common issue is not returning focus to where it came from. For example, opening a menu or dialog and then closing it, but leaving focus somewhere unexpected instead of restoring it to the original trigger.

That kind of break in continuity can make an interface feel disjointed, especially for keyboard users who rely on predictable navigation.

Focus management is really about continuity. It’s not just about where focus goes next — it’s about making sure the user always understands their position in the interface as things change.

If keyboard accessibility is about movement, focus management is about orientation.

Accessible Names

One of the easiest accessibility issues to introduce is giving an interactive element no meaningful name.

If you’ve ever tabbed onto a button with a screen reader and heard “button” instead of “Search button” or “Close button”, you’ve experienced the problem first hand.

An accessible name is just how assistive technologies identify an element to a user. If that name doesn’t exist, or it isn’t descriptive enough, then the user is left guessing what the functionality should be.

This is another reason why native HTML should always be your first choice. As we discussed earlier, HTML gives you a lot of accessibility for free, and accessible names are a great example of that. If we look at a <button> , this button gets its accessible name from the text inside of it. A form field gets its name from the associated <label> . If you’re using semantic HTML correctly then you’re already most of the way there.

// Example 1
<label for="expire">Expiration date (MM/YYYY): </label>
<input type="text" name="expire" id="expire">

// Example 2
<label
  >I agree to the terms and conditions.
  <input type="checkbox" id="terms" name="terms" />
</label>

Both examples achieve exactly the same outcome. In the first example, the <input> is associated with the <label> using the for and id attributes. In the second example, the <input> is nested inside the <label>, which creates the association automatically (this is something we’ll cover in a later post). While both approaches are spec-compliant, explicit binding (Example 1) is the gold standard for enterprise architecture. Nesting inputs implicitly (Example 2) can still confuse certain voice-dictation software and older screen readers. Stick to explicit IDs to ensure bulletproof coverage.

If we think of an icon only button, it may only have an icon depicting a magnifying glass and no text. Visually, this might make sense to a user to know that it’s a search button, however, for screen readers it will be announced just as “button” leaving the user wondering what this button does.

This is where ARIA becomes useful. Adding in an aria-label=”Search” gives the button a meaningful accessible name without changing what is displayed visually. The important thing isn’t that you’ve used ARIA — it’s that you’ve give users enough information to understand what the button actually does.

ARIA — When it’s Appropriate (and When it Isn’t)

If there’s one thing I hope that you take away from this article, it’s that ARIA isn’t the starting point for accessibility.

It’s an incredibly useful technology when it’s used for the right reasons, but it should never be the first tool you reach for.

If HTML already has an element that does what I need, use it.

A <button> is already a button

A <nav> is already navigation

An labelled <input> already shows it purpose to assistive technologies

Adding ARIA to these elements often provides no additional benefit and, in some cases, can actually make the experience worse if it’s implemented incorrectly.

Where ARIA can really help is when you’re building something that HTML doesn’t provide out of the box, things such as:

• Complex tab interfaces
• Comboboxes
• Autocompletes
• Custom listboxes

In those situations, ARIA helps communicate information to assistive technologies that native HTML alone can’t express.

One phrase you’ll hear a lot in accessibility circles is

No ARIA is better than bad ARIA

Use ARIA when you genuinely need it, not because you feel like every accessible component should contain it.

Conclusion

If you’ve made it this far, hopefully one thing has become obvious:

Accessibility isn’t about memorising hundreds of WCAG success criteria or throwing ARIA attributes everywhere.

Its about building on good foundations.

• Use semantic HTML
• Create logical structure
• Make everything work with a keyboard
• Manage focus when your interface changes
• Give controls meaningful names

Once those become habits rather than afterthoughts, you’ll find that many accessibility issues never appear in the first place. Accessibility isn’t something you need to add at the end of the project and it isn’t something that QA should remind you about. It is a principle that should baked into development from the very start. If accessibility becomes one of your engineering defaults, you’ll spend far less time fixing problems later — and you’ll build experiences that work for far more people from day one.

This article isn’t intended to replace the specifications or guidance from W3C. It’s a set of principles that I’ve found myself coming back to time and time again throughout my career and I wanted to share some of the lessons I’ve learnt over the years in the hope that they help other developers build accessibility into their work from the very beginning. If you’re new to accessibility, I’d encourage you to start here. Once you get these foundations right, everything else will become a lot easier.

Accessibility by Default is a series where I explore practical accessibility techniques from the perspective of a frontend engineer. Rather than repeating specifications, the goal is to explain the engineering decisions and patterns that make accessible interfaces easier to build from the start.

You can find the full series on my profile

Accessibility by Default: Foundational Principles for Building Accessible Interfaces was originally published in Design Systems Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.