Responsible Web Applications

Accessible Web Design

We now come to accessibility. Here I feel that I can only scratch the surface of the different things that we should consider. I also am learning new things all the time, so I'm sure that this list is not exhaustive. But I do think it is a good starting off point.

Headings

Don’t skip heading levels.

In your HTML Document, you need to ensure that your document hierarchy is complete and doesn't skip levels. Otherwise, users who depend on assistive technologies will get confused because it will seem like content is missing.

This is a mistake that many developers make, because we pay attention to how the heading appears visually without making sure that an h2 is always directly followed by a h3.

Landmarks

We should make sure that we use elements like main and header because then we get HTML landmarks out of the box. This makes the page much easier to navigate.

Note that the main element is not well supported for IE11, so if you have to support older browsers, you should also consider using skip links.

nav Element

When you are providing links for a user to navigate within your page (e.g. a navbar or a table of contents), you should wrap them in a nav.

label Element

Always add a label to let assistive technologies know which data is supposed to be entered in an input field.

<label>
	First Name
	<input type="text" value="name" placeholder="Jane" />
</label>

Here we either wrap the input field directly in the label, or we can use the for attribute and link it to a specific input field.

Here it is important to not use the placeholder attribute to label the input field. The placeholder attribute should be used to show an example of how the data we expect should appear. This is particularly important for users who have congnitive disabilities, because when the instructions in the placeholder disappear, they may not remember what they were supposed to enter into the field. Please also read this article about why placeholder are problematic.

List Elements

Using lists (an unordered list, an ordered list, or a description list) for things in a UI will also add extra context for assistive technologies. For instance, it will tell assistive technologies how many elements are contained in a list.

In practice, description lists can be difficult to style because we are not allowed to add an extra div as a wrapper around the dt and dd elements. For this reason, I've also done some experiments about how to best group information in the UI. Here there isn't a single correct solution. You will have to find out what works best for your UI.

Update: Originally, I discussed having difficulties styling description lists. This statement is no longer correct for modern browsers which implement the HTML 5.2 Recommendation because they now allow a div as a wrapper around the dt and dd elements.

Accordions

If we need an accordion, or an element which shows/hides a content area, we can use the HTML details element.

<details>
	<summary>Toggle Button</summary>
	Content which will be expanded/collapsed when clicking the
	summary element
</details>

We can also implement this in JavaScript using a button and the aria-expanded attribute. The aria-expanded attribute adds context information to the button which will tell the screenreader if the area that the button is toggling is currently collapsed or expanded.

I have seen incorrect implementations of this where the developer thought that the attribute was intended to be added to the content block which is expanded or collapsed, but this is not the case and that implementation would be confusing to any user of an assistive technology. If we do spend the effort to set aria roles in our application (which we should), we need to test our application and make sure they are used correctly! No aria usage is better than incorrect aria usage.

I have implemented this behavior many times, and when I do, I prefer to use a custom element and activate the toggle with progressive enhancement. This means that my toggle button is hidden by default before JavaScript is activated, and the content area that is to be collapsed/expanded will only be hidden once JavaScript is activated.

The contract for the toggle-button component that I usually end up writing therefore usually looks something like this:

<button is="toggle-button" data-target="#section2"
		  aria-expanded="false" hidden>
		Toggle Section 2
</button>

aria-expanded is an attribute of the BUTTON which tells assistive technologies if the content area that is being expanded/collapsed is currently visible or not.

And my toggle-button implementation usually looks a lot like the following (I really need to standardize this and publish a custom element one of these days...):

class ToggleButton extends HTMLButtonElement {
	connectedCallback () {
		this.removeAttribute("hidden");
		if (this.getAttribute("aria-expanded") !== "true") {
			this.setAttribute("aria-expanded", "false");
			this.target.classList.add("hide");
		}
		this.addEventListener("click", this.toggle.bind(this));
	}

	toggle () {
		let classList = this.target.classList;
		if (classList.contains("hide")) {
			classList.remove("hide");
			this.setAttribute("aria-expanded", "true");
		} else {
			classList.add("hide");
			this.setAttribute("aria-expanded", "false");
		}
	}

	get target () {
		return document.querySelector(this.getAttribute("data-target"));
	}
}
customElements.define("toggle-button", ToggleButton, { extends: "button" });

Here is a code demo of this component.

aria-label and aria-labelledby

Sometimes we have visual elements which add information to the UI, but are missing in the UI. For these cases, we can use an aria-label attribute with a textual description of what the visual element is showing. If there is already a UI element available, we can also use aria-labelledby and reference the HTML id of the existing element. The HTML title attribute is not well supported by assistive technologies, so it should not be used to do this.

Here it really helps to test your UI in a screenreader so that you can figure out where extra labels would be helpful 😉.

Hiding content visually (but not from screenreaders)

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

Sometimes we want to hide elements from our UI. If we use a CSS rule like display: none; this not only hides the element visually, but also hides it from assistive technologies. We can use the previous CSS snippet (or one like it), to hide the content visually without removing it from the accessibility tree.

Hiding content from assistive technologies

In the same vein, sometimes we add visual elements to our UI which are not necessary for assistive technologies and could potentially cause confusion or unnecessary noise. This could be the case, for instance, when we add icons to our visual design in addition to existing textual labels. We may then want to hide these from assistive technologies using the aria-hidden attribute.

Descriptive alt text for images

When using images in a user interface, we need to set the alt attribute for the image. This alt-text should provide a description of the same information that we are trying to convey visually with the image that we have chosen. This guide provides more information about alt-texts.

Adding clear focus styles

By default, the browser will add focus styles to the UI to indicate to users which element on the screen is currently active. This is especially important for keyboard users, who need the focus styles in order to correctly navigate throughout your page.

If you find the default focus styles irritating in your design, you can customize them with the :focus CSS pseudo-selector. However, here it is very important that you still provide a focus style which has a high contrast and is easily identifiable within the UI.

Setting focus correctly

As long as you are writing only HTML and CSS, there isn't any good reason why you would want to mess with the focus within your webpage, because the semantics and structure of HTML is very well designed. However, when we begin to modify the HTML of our application with client-side JavaScript, we need to think about the focus and if we need to update it as well.

For instance, if we are adding content to our DOM with JavaScript, as I did with this “Show More” Pagination Example, we should consider whether we should move the focus to the new content after it has loaded.

In this case, we need to make absolutely sure that you test the application with a screenreader and keyboard to ensure that the focus is set correctly. There is little that can break your UI more than incorrectly setting the focus.