DEV Community: Frank van Eldijk-Smeding

Are our links visually accessible?

Frank van Eldijk-Smeding — Thu, 25 Aug 2022 12:59:00 +0000

When I wrote about the accessibility of links, I’ve focused on screen reader & voice recognition users. But this time I’ll focus on what visually goes wrong for our links.

So, let’s get started and figure out what those barriers are and what we can do to prevent them from happening.

A simple link inside a paragraph, what could go wrong?

While browsing the web, I keep noticing a design trend more often than before. And that’s the styling of their links.

Having only a color difference to separate them from the rest of the content. You might wonder what’s wrong with only using a color to convey meaning, so let’s find out together.

Lost in a sea of text

I’ll show you two examples, both showing two paragraphs and a link somewhere in the middle.

The first example is what people without a color vision deficiency (better known as color blindness) see. And with the second example I’ve simulated a type of color vision deficiency called Protanopia.

Do note that the simulated effect might differ from reality. This is due to a lot of factors (e.g. the algorithm used, severity of the color vision deficiency, monitor settings, etc).

Are you able to spot the link in the second example? I bet it wasn’t as easy as the first example. So, what could we do to prevent this from happening?

More weight please

So, what about giving our links more font-weight? Surely that will solve the problem, right?

Not ideal I’m afraid. Even though the link stands out more compared to the rest of the content. We’ve introduced a new problem. It’s still unclear which is just bolded text and which is the link.

Underline to the rescue

What our links — or rather our users — need, is an underline. It’s still often removed (and I’ve been guilty of this in the past as well) because of aesthetic reasons.

Yet, it’s the best visual cue for a link that’s available. And most likely, it’s what our users will expect. So, let's add some underlines shall we.

In both examples the link stands out, even with a loss of color.

Conclusion

When we’re developing (or designing) for our users, we shouldn’t use color as the only visual cue
Using underlines for our links is what our users will expect the most, don’t make them think or second guess!

How accessible are links and buttons?

Frank van Eldijk-Smeding — Fri, 10 Dec 2021 14:36:59 +0000

Links and buttons are one of the main basic elements that you’ll find on any website. Yet, a lot of them are not as accessible as we would like. And we’re bound to make mistakes as developers, if we don't know how they're understood by assistive technologies.

In this short article I'll focus on screen readers and voice recognition and how they deal with links and buttons. I'll not cover every possible problem that could happen. I'm going to reserve that for a different article which I'll publish soon.

Before we continue, I want to avoid any confusion upfront. When we’re talking about links or buttons, I assume that they're using the proper semantic element, a <a> and <button>.

Using a different HTML element — like a <div> which looks like a link or a button — might not be set up right. And this could cause other problems for assistive technologies. If you want to know more on this, I've written an article on why we should prefer semantic HTML.

How assistive technologies understand a web page

This is possible through the use of many accessibility API’s. The platform that the browser runs on uses one of those API’s to read the content of a web page.

How this process actually works in the background would be too much for this article. If you want to learn the details I recommend you to read Web Accessibility with Accessibility API. It’s a great article written by Léonie Watson.

The part that’s important for us to know is that those API's expose certain information. This happens for every object in the DOM. This information is crucial for assistive technologies to understand what each object means.

There are two pieces of information I want to focus on, and those are the role and the name. The role of the DOM object exposes its purpose. It could be a link, a button or something else like an image. The name of the DOM object gives its identity. It’s also referred as the Accessible Name.

So, let’s use the example above to quickly recap what we’ve learned.

The <main> element will have the role of “main”. The name is empty because we didn’t supply one.
Each <p> element will have the role of “paragraph”. Again the name is empty since we didn’t supply one.
Every <a> element will have the role of “link”. The name will be “Read more”. This happens because the name — or Accessible Name — is determined from a list of possible options. And in this case it was the value inside the <a> element that’s used for the Accessible Name.

I’ve picked this example on purpose because it’s quite common to see a list of cards. Each card having a title, some text and at the bottom a “Read more” link.

So, let’s see which problems could happen for screen readers & voice recognition if we leave the example above untouched.

Potential problems for screen readers & voice recognition

When a sighted user sees a “Read more” link that’s near other elements, they’re able to group them together. The context behind the “Read more” link is then related to the text and the title. It becomes clear what to expect when they press the link. This happens because of the Law of Proximity and/or the Law of Common Region, depending on how the elements are visually styled.

Yet, people who rely on screen readers are usually not able to scan the page, and group elements based on visual proximity. So, in this case the “Read more” link doesn’t have any meaning to them.

For people who depend on voice recognition, might be able to group elements together. But, they’ll have a different problem. To interact with elements they say “Click” — I’m using Voice Control on MacOS — followed by the Accessible Name of the link. This will then press the element that matches the Accessible Name.

So, in our first example it would be “Click, Read more”. But, this will number each “Read more” link. Because the voice recognition software doesn’t understand which link they meant.

Both cases lead up to a poor user experience and could end up in frustration. How could we solve this?

The solution (well, one of many)

Well, there are a couple options available to us. But, let’s focus on one solution for now to keep this article brief. I’ll write an in-depth article on a lot more problems/situations and solutions soon.

If we remove the “Read more” link, we could solve both problems. But, what becomes our link then? Well, the entire card could turn into our link. Then give the <a> either an aria-label, matching the value of our title. Or use an aria-labelledby, which then refers to our <div class="title">. Let’s check it out!

When a screen reader user tabs through the links, or use a shortcut to get a list of links. They’ll hear each link announced with the name of the title instead of “Read more”.

The problem with voice recognition is also solved. Because it’s now possible to use the command “Click” followed by the name of the title.

If you’ve liked this piece of content and you want to get regular updates on other things I write about then follow me on Twitter. And if you have any comments or questions then don’t hesitate to DM me!

Conclusion

Assistive technologies understand the content of a web page through the platform’s accessibility API.
Links and buttons should be clear on their own, and not depend on their surrounding context to make sense.
Voice recognition software have shortcuts to interact with elements
Command “Click” with the name of the label. The label name needs to match the Accessible Name

The rules on using ARIA

Frank van Eldijk-Smeding — Wed, 24 Nov 2021 10:54:38 +0000

In my previous post about the differences between the ARIA labeling variants I mentioned the first rule of ARIA — which is often mentioned as “Don’t use ARIA” — and that I would dive deeper into the five rules of ARIA.

If you never heard of ARIA before, let me give you a short introduction. It’s a set of attributes to enable frontend developers create accessible web apps. Look at it as an add-on, or a layer, on top of HTML. Often it’s not necessary to use ARIA because HTML offers a native solution for us. But sometimes our UI components are so complex that they just don’t fit anywhere in the native HTML options. Then it’s time to bring out ARIA and use it to create an accessible experience for everyone.

But, we should be careful with ARIA, because of its double-edged sword characteristic. When it’s used properly, it greatly improves the user experience. But when it’s used incorrectly — or partially — it could break the user experience. To a point where it's completely unusable.

Enough about the intro, let’s go over the five rules on how to use ARIA!

1. Prefer semantic HTML over ARIA

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

We should prefer to use the semantic HTML option, if it's available to us. We shouldn’t opt for ARIA for the sake of using ARIA. Although the intent of ARIA is to make things accessible, it’s not the only option available to us. It’s still the only option when things get complex in the UI. But, we have to remember that ARIA came before HTML 5. And when HTML 5 came, it introduced a lot of semantic elements that we no longer have to reproduce through ARIA.

Let’s elaborate on this further with an example.

Let’s not do this

<div role="button">This is a button</div>

Let’s do this instead

<button>This is a button</button>

What’s the difference between role="button" and <button> in this example? They’re the same semantic wise. Both elements should are buttons. So why should we prefer semantic HTML over ARIA? Well, if we would use the role="button" approach we’re not even halfway of what a semantic <button> would give us.

Let’s take the <div role="button"> example and see what’s missing, step by step. The element has its role, so it's recognised as a button. But we can’t focus this element with a keyboard, because there’s no tabindex attribute present. Which the <button> would have given us, out of the box.

It's not only focus management we're missing. It's also the keyboard functionality for interacting with the button that's missing. For instance, when a button has focus, we should be able to press the Space key to activate the button. To check which other interactions we’re missing out on I recommend to read the design patterns for a button from W3C.

In short, let’s use semantic HTML over ARIA, so that we don't have to do the work! This is the main takeaway that I want to give you.

2. Don’t alter the meaning of a semantic HTML element

Do not change native semantics, unless you really have to.
– W3C, Second rule of ARIA

When we use a semantic HTML element its meaning has been implicitly given by the element. In other words, a <button> has the role of a “button”. But, what happens if we’re using that same <button> and we give it the ARIA role="header"? Well, we've explicitly gave it a different meaning. And this could lead to unwanted side effects.

Let’s take an unordered list, <ul>, as an example. Everything we expect from an <ul> are right. For instance, it should have a list of <li>. And if we leave it at that, screen readers will be able to understand it. We enable the screen reader to announce how many list items are present. And it will then proceed to announce each list item one by one.

But, wen we add the role="navigation" on the <ul>, it becomes a navigation landmark. The semantics are overridden. and screen readers have lost the ability to do what they could do before. Leaving screen reader users guessing what it means.

3. All interactive elements must be usable by a keyboard

All interactive ARIA controls must be usable with the keyboard.
– W3C, Third rule of ARIA

The third rule is somewhat linked to the first rule. Let’s use example from the first rule — the <div role="button"> — to explain how they relate to each other. We’ve learned, in the first rule, that when we use the role attribute that we're not done. That we don't have any keyboard functionality. So again, for this rule it's best to go for the semantic HTML element. Because by doing so, we gain the keyboard functionality out of the box.

But, what if we have a complex UI component — often referred as a custom widget — which needs to be interactive. Well, we first need to determine what our complex UI component should act as. To do that we could visit the design patterns and see how it fits. From there we could check which keyboard interactions are expected. In other words, what do we expect to happen when we press the Space key.

4. Focusable elements shouldn’t be hidden

Do not use role="presentation" or aria-hidden="true" on a focusable element.
– W3C, Fourth rule of ARIA

The fourth rule focusses — no pun intended, I swear — on ensuring that focusable elements are present in the Accessibility Tree. Otherwise, they're hidden from assistive technologies (e.g. a screen reader).

The aria-hidden="true", role="presentation" and role="none" attributes may look similar. But their intent is quite different!

aria-hidden="true" will remove the element and all its child elements from the accessibility API. This means that it won’t show up in the Accessibility Tree. And if it’s not present there then it’s invisible to assistive technologies.
role="presentation" and role="none" will remove the semantic meaning of an element while still exposing it to assistive technology.

The role="presentation" and role="none" attributes are the same. The role="none" attribute is actually an alias for role="presentation".

When the button has the aria-hidden="true" attribute, it’s still present in the HTML DOM. So it's still possible to focus the button with a keyboard. But, when we navigate with the screen reader, it will not know of the button's existence.

We shouldn't use the aria-hidden="true" attribute on any focusable or interactive element. Because it will then be impossible to focus or interact with such elements for a lot of people.

5. All interactive elements require an Accessible Name

All interactive elements must have an accessible name.
– W3C, Fifth rule of ARIA

All interactive elements (e.g. an <input>) require an Accessible Name. Otherwise, assistive technologies have no clue what the interactive element means.

Let’s take a plain <input> with a <span> next to it, which acts as the visual label. So no <label>, aria-label or aria-labelledby. What would a screen reader announce, when the user has focus on the input?

<span>Username</span>
<input type="text">

Voice Over on MacOS would say something like: Edit text

The screen reader user is confused and needs to guess what the input means, since they can only hear “Edit text”.

This would impact voice recognition users (e.g. VoiceControl on MacOS) as well. If the Accessible Name is present, then it's possible to interact with the <input> element directly. For example, with the VoiceOver command: “Click [insert accessible name]”. If the Accessible Name isn't available, they need to resort to other means to interact with the element. Which could seriously affect their user experience.

How could we provide the Accessible Name?

There are three separate techniques to provide the Accessible Name:

For <a> and <button> we provide the Accessible Name through the link text/button value we’ve given them
For <input> elements we provide the Accessible Name through either a explicit <label>, aria-label or the aria-labelledby
For anything else (e.g. custom elements, landmarks, etc) we provide the Accessible Name either through aria-label or the aria-labelledby attributes

If you’ve liked this piece of content and you want to get regular updates on other things I write about then follow me on Twitter.

Conclusion

You’ve made it to the end! That was quite a lot of information on how we should use ARIA. So, let’s summarise all the things we’ve learned:

Prefer semantic HTML over ARIA, because they’ll do the hard work for us!
When we use ARIA instead, check the design patterns to check what’s expected.
We shouldn’t alter the meaning of semantic HTML, otherwise we could end up having nasty side effects
Keyboard focus/navigation isn’t the same as screen reader focus/navigation
We shouldn’t hide focusable elements, otherwise they’re not usable for assistive technologies
All interactive elements should have an Accessible Name. Otherwise, (again) it won’t be usable for assistive technologies

The differences between the ARIA labeling variants

Frank van Eldijk-Smeding — Thu, 21 Oct 2021 08:19:42 +0000

The differences between the ARIA labeling variants

In this bite sized post, I’m going to take the time to explain the differences between aria-label, aria-labelledby and aria-describedby. Before I read the documentation on these attributes, they confused me because they seem so similar, while there are, in fact, some crucial differences between the three. I hope by the end of this post you’ll know when and how to use these three attributes.

Before I go on and explain the differences, I do want to stress something out which is the first rule of using ARIA: Don't use ARIA. This almost sounds like the first rule of Fight club. I’ll be honest here and say that I found this rather confusing in the beginning. Only after reading about it and understanding the intent behind the rule did it click with me. I think it might have been better to name the first rule like this: Prefer native HTML over ARIA. We shouldn’t use ARIA attributes without considering using the semantic HTML element first. I’ll dive deeper into the five rules of using ARIA in a different post since it’s beyond the scope of this topic.

The aria-label

The aria-label attribute is somewhat similar to the <label> element. It doesn't have some of the advantages that the <label> element has, but its purpose is the same. Giving context, through the Accessible Name, to the element it's associated with.

Unlike the <label> element (which is its own element) the aria-label attribute needs to be put on the element itself. It could look like this:

<button aria-label="Close">
  <svg>
    <!-- svg content -->
  </svg>
</button>

The aria-label attribute takes a string value, which is then used to create the Accessible Name for the <button> element. The common use case for the aria-label attribute is when we’re not able to use the native <label> element, while still providing context for the Accessible Name.

The aria-labelledby

Although the aria-labelledby attribute may look similar to aria-label, it works quite different. Instead of a string value, it requires the ID of the element we’re referencing.

Let’s say we would want to give meaning to the <button> through the ID of the <svg>element. It would look like this:

<button aria-labelledby="close-icon">
  <svg aria-label="Close" id="close-icon" >
    <!-- svg content -->
  </svg>
</button>

We could view aria-labelledby, in this regard, that it’s inheriting the context from the <svg>. The benefit of this approach is that we gain flexibility on how we give meaning to our <button>. The bad part of this approach is that the support isn’t that great.

Another big difference, over the aria-label, is that it could also accept a space-separated list of element IDs. This lets us “build” a certain context from different parts of the UI. For now I haven’t found a practical example to go with this.

The aria-describedby

The aria-describedby attribute is used to add a description for the element it’s used on. I wanted to include this attribute as well next to the aria-label and aria-labelledby since there’s some confusion on what they mean and when we should use them.

<label for="password-input">Password</label>
<input id="password-input" type="password" aria-describedby="password-input-description">
<span id="password-input-description">Password must contain at least 8 characters<span>

In the example I’ve used the aria-describedby attribute to give a description to a password input. And because we’ve attached the description to the input field it will be recognized by the screen reader, enabling it to announce the description after the label of the input.

Voice Over on MacOS would announce something like this: Password, secure edit text. Password must contain at least 8 characters.

Conclusion

The aria-label attribute accepts a string value which provides the Accessible Name on the element it’s used on
The aria-labelledby attribute accepts either a single ID or multiple ID’s which will be used for the Accessible Name
We should only use the aria-label, aria-labelledby and aria-describedby on interactive elements, landmarks or elements that have an explicit
When both aria-label and aria-labelledby attributes are present on the same element, the value of aria-labelledby will take priority

How to have an accessible input while the label isn’t present?

Frank van Eldijk-Smeding — Sun, 03 Oct 2021 19:20:19 +0000

In another bite-sized post I want to take the time to cover a common UI pattern that you’ll find on almost every website. Which is an input field with no visual label at all. Just a placeholder and perhaps with an icon.

I'll explain what's missing or what's flawed with the approaches you'll see on on most websites. As an example we’ll use a search field since it's quite common and it fits the UI pattern quite well.

The bare essentials and why it's flawed to begin with

Let's dive into a basic search field example which represents this pattern. An input with no label.

<form role="search">
  <input type="search" name="search" placeholder="Find repositories.."/>
</form>

Perhaps you've noticed — or you already know this — that the input element has search as its type instead of text, and you might expect the latter. The difference of using search over text is that the user is able to reset the search query through the Esc key and it’s announced as a search

So our search field has a placeholder with ”Find repositories..“. It doesn't have a label associated with the input field, because why should we have one if it's visually not there. Right?

What’s so flawed about it?

You might wonder what the problems are with the example above? Well, in this example there’s two problems I’ll cover.

The placeholder is used as a substitute for the label.
People who use Voice Control, or something similiar, aren’t able to interact directly with the search field.

Placeholder shenanigans

When you do a search for placeholder combined with accessibility, you'll see a lot of articles on why you shouldn't use placeholders to begin with. This is because the placeholder attribute is tied to a lot of accessible problems. I’ll cover those problems on a different time because it’s beyond the scope of this post.

The main takeaway I want to share about the placeholder attribute is that we shouldn’t depend on it. The intent of a placeholder isn’t the same as the intent of a label. And this is important for assistive technologies, like screen readers. To give you an example. In 2019 JAWS, one the biggest screen readers¹, changed how they processed the placeholder attribute. Before this change the placeholder attribute was completely ignored.

Voice Control can’t be fully utilised

The second problem is that assistive technology like Voice Control can’t interact with the search field directly. What do I mean by that? Well, it's not possible to use the command “Click search”. This command in Voice Control lets you select any interactive element based on the name of the label. Considering that we don't have a label (yet), we're not able to use this command.

So how could we solve this?

We have a couple of options at our disposal:

The first option is to add an explicit label. If you want to read more on what an explicit label is and how we could add them: The what, why and how on labels. The twist in this situation, however, is that we’ll hide the label visually through CSS.
As a second option we could use the aria-label attribute. This doesn’t require any CSS magic to hide it since the aria-label attribute isn’t visually shown.

First option: the invisible label

The first step is through adding an explicit label for our search field:

<form role="search">
  <label for="search-input" class="sr-only">Find repositories..</label>
  <input id="search-input" type="search" name="search" placeholder="Find repositories.."/>
</form>

Note: If a placeholder is present with a label, make sure that the values match exactly. Yes, including the dots. Otherwise the screen reader — in this case Voice Over on MacOS — will announce the value of the label followed by the value of the placeholder.

We’re not done of course, since we now have a label that’s still visible. And the requirement from the design (or from somewhere else) was quite clear. We shouldn’t have a visible label. So the next step is to perform some CSS magic which will turn our label invisible.

You might have spotted the sr-only class on the label. The following snippet is the CSS magic that will turn our label invisible.

.sr-only { 
    clip: rect(0 0 0 0);
    clip-path: inset(50%);
    height: 1px;
    overflow: hidden;
    position: absolute;
    white-space: nowrap;
    width: 1px;
}

Credit for this CSS snippet goes to Scott O'Hara ²

Even though it’s visually not there, the label still remains visible in the Accessible tree³ which is exactly what we need to make our search field accessible.

Second option: the other invisible label, aria-label

If, for whatever reason, it’s not possible to add an explicit label then we’ll turn to the second option. The aria-label attribute. It has the same semantic meaning as the label, so it’s doing a lot better than the placeholder attribute. And this is because the aria-label tries to act like the native label element. Let’s add it to our search field.

<form role="search">
  <input aria-label="Find repositories..." type="search" name="search" placeholder="Find repositories.."/>
</form>

Because aria-label is just an attribute and not a HTML element, we don’t need to do any CSS magic to turn it invisible.

Conclusion

So this is it. We’ve explored two options to make our search field more accessible. The explicit label and the aria-label attribute. A short recap.

We shouldn’t use the placeholder attribute as a substitute for a label
A label is required if we want to use Voice Control’s command “Click”
When a HTML element is visually not shown it doesn’t necessarily mean it’s gone from the Accessibility Tree
Don’t forget to match the text from a label with the placeholder. Unless you want the screen reader to announce it twice!
If it’s not possible to add an explicit label we should use the aria-label attribute

The what, why and how on labels

Frank van Eldijk-Smeding — Wed, 09 Jun 2021 04:31:36 +0000

Today I want to take the chance to tell you about the importance of labels and what they have to offer us. So with this bite-sized post I’ll cover the following: what a label is, what a label does if you use them, how we can use/add labels and which other HTML elements should have a label.

So, what's a label to begin with?

Well, the <label> is a simple HTML element that holds a text value¹, which explains something about the related input element. And that's basically it for our humble label element. So how could such a simple HTML element have such an impact? Let's find out together.

Why should we use labels?

Why we need to use labels, is to understand what they’ll do for us when we use them. So, what do we gain when we use a label? Well, when we’ve paired a label to an input field it does two things:

Increases the interactive area of the associated input field. The browser does this for us when it sees a label paired with an input field. But what does it mean when the interactive area is increased? Well when the user clicks on the label it will instead focus on the associated input field. This improves the UX on mobile devices and for users with a physical disability (e.g. tremors).
Screen readers are able to announce the name (the associated label) of an input field when it's focused. See the examples down below what the difference is with and without an associated label.

Without label

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

This will say: "edit text blank" - on MacBook Voice Over

With label

<label for="username_input">Username:</label>
<input id="username_input" type="text" name="username"/>

This will say: "Username, edit text" - on MacBook Voice Over

How could we add a label?

There are two approaches for adding a label. The first approach is called implicit and the second approach is called explicit. We'll cover implicit first and then I'll continue with explicit. And I’ll explain why the second approach is the recommended option.

Implicit

With the implicit method we use the label as a wrapper/container. It doesn’t require anything else from us. Just put the input field inside and you’re done. You’ve added the label and associated it implicitly with an input field.

<label>
    Email:
    <input type="text" name="email" />
</label>

Let’s move on to the second approach.

Explicit (recommended)

With the explicit approach we don’t use the label as a wrapper/container. And we're not required to put it directly before the input field in the DOM* to make it work (which you’ll see in every example, even the one down below). So how could we tell HTML that the label we’re using is for specific input field? Through two special attributes: for & id.

<label for="email_input">Email:</label>
<input id="email_input" type="text" name="email"/>

The label element has a for attribute that will have a certain value. The input element on their turn has an id attribute which also holds a certain value. You may have guessed it, without peeking at the example above, that both attributes need to have the same value. By using the same value in the for and the id attribute you'll explicitly associate the label to an input field.

So why is this the recommended approach? To put it simply, because of accessibility support². At the moment it's not possible to select an input by its name (the associated label) through voice command (e.g. Voice Control from Apple). I've tested this myself on a MacBook with Safari and Voice Control. And it just didn't work, no matter how many times I've tried. I'll add a link down below for the current support results

Now we know how to use and associate a label with an input. But are we limited to just an input or are there more potential friends for our label? There sure are and they're grouped together under "labelable" fields.

Labelable, excuse me?

As a non English speaker, that word is just a mouthful for me. Moving on. So this term groups a list of elements together that should be paired with a label³. I won't go into it further details what each element does on its own.

Labelable fields:

button
inputs
meter
output
progress
select
textarea

The odd one in the list above is the button element. Even though it's considered a labelable element it should not be paired with a label. This is because the button already comes with a label, which is the text value inside the tags⁴. When using <input type="button" value="Sign up"/> the label comes from it's value attribute.

Credit goes to InHuOfficial for pointing out that I've missed this in the original post.

Conclusion

When labels are used screen readers are able to do their work and assist their users
Labels increase the interactive area for input fields which improves the user experience
Using labels explicitly is the recommended option when pairing up with a labelable element
Labels used implicitly lack support for voice commands

In the next bite-sized blog we’re going to learn what to do when we can’t show a label visually. For whatever reason that might be.

DEV Community: Frank van Eldijk-Smeding

Are our links visually accessible?

A simple link inside a paragraph, what could go wrong?

Lost in a sea of text

More weight please

Underline to the rescue

Conclusion

Further reading

How accessible are links and buttons?

How assistive technologies understand a web page

Potential problems for screen readers & voice recognition

The solution (well, one of many)

Conclusion

The rules on using ARIA

1. Prefer semantic HTML over ARIA

2. Don’t alter the meaning of a semantic HTML element

3. All interactive elements must be usable by a keyboard

4. Focusable elements shouldn’t be hidden

5. All interactive elements require an Accessible Name

How could we provide the Accessible Name?

Conclusion

The differences between the ARIA labeling variants

The differences between the ARIA labeling variants

The aria-label

The aria-labelledby

The aria-describedby

Conclusion

Further reading

How to have an accessible input while the label isn’t present?

The bare essentials and why it's flawed to begin with

What’s so flawed about it?

Placeholder shenanigans

Voice Control can’t be fully utilised

So how could we solve this?

First option: the invisible label

Second option: the other invisible label, aria-label

Conclusion

The what, why and how on labels

So, what's a label to begin with?

Why should we use labels?

Without label

With label

How could we add a label?

Implicit

Explicit (recommended)

Labelable, excuse me?

Conclusion

References