When we talk about users who might miss cues like colors or icons, who are we really talking about? According to the World Health Organization (WHO), about 15% of the world’s population experiences some form of disability. Approximately 1.3 billion people live with some form of vision impairment. Thereof, 36 million people are blind. Mild and severe vision impairments bring trouble reading content on a website. As developers, the types of disabilities we need to keep in mind when we develop include auditory, cognitive, neurological, physical, and visual impairments. Accessibility doesn’t just help users with permanent disabilities, it can also help users with “temporary” or “situational” disabilities.

Simply put, accessibility describes whether a product is usable by people of all abilities. We see these considerations all the time in our everyday lives. Think about accessible parking and bathroom stalls, wheelchair ramps, braille or raised lettering — I’m sure you can think of more examples. There are also considerations we have to make in the digital world, or our websites and applications will be inaccessible to some people. International standards have been outlined for digital accessibility and are defined by the Web Content Accessibility Guidelines (WCAG).

Semantic HTML & Color Palettes

A frontend developer has a responsibility to present visual information that looks good and gives users cues to help them understand content quickly. Even a static website is more than a collection of words. The pages have titles, links, important callout information, etc. The title may be bold, accented with a sharp color, or in a large font size. In the body of the text, words are grouped into sentences that end with periods and have links within. Certain words in a sentence may be emphasised with bolding, underlining, or italics as well. These examples barely scratch the surface of the many, minute details of visual web design.

These components may seem basic and unimportant, but for many people, accessing and reading text on a web page is difficult. Assigning a strong color palette to these elements help strengthen accesibility for the visually impaired. Making fonts a strong color for viewing, differentiating links from the plain text surrounding it, and the sharper the contrast, the better the experience.

It’s good to note that a well structured semantic HTML website helps to improve your SEO. A search engine bot is, for example, blind, can’t hear, and has the cognitive abilities of a young child. So he is one of your most important website visitor. If he cannot properly access your website, you will get a lower rank in the search requests. Utilizing tags to convey meaning assist SEO and accessibility equally. If the page contains an article, it is good practice to contain the article content within an <article> tag. The <div> tag should really only be used for content that does not need to convey something explicit.

Font Sizes

It’s pretty common to set font sizes with pixels, but that’s a mistake. A user who has a hard time seeing might turn up the default font size in their browser, but pixels won’t respond to that change. Try using root em (REMs) as your unit of measurement instead. REMs are responsive to the root element, so if a user changes their font size, your site will respond accordingly.

Font Styling

Always favor proper HTML markup over styling done with CSS. For example, the <strong> tag carries meaning and makes text bold. Visually impaired and sighted users will both be able to tell what’s in the strong tag. The same applies for italics with the <em> tag. In contrast, if you use a custom class to apply styling, that won’t carry any semantic meaning, and the emphasis will be lost on visually impaired users.

Font Color

I mentioned this briefly above, but as a simple rule, don’t use color exclusively to convey meaning. It can be a nice addition, but you should always provide explicit instructions or error messages to your users along side our other visual cues.

Contrast

When we talk about contrast, we’re talking about the difference in brightness between two colors. This goes all the way from 1:1 (white on white, which isn’t readable) to 21:1(black on white, which is very readable). To ensure that users can read your content, you should always aim for your text to have a contrast of at least 4.5:1. User interface components and large text can be slightly lower, at 3:1. If the element is a logo, or purely decorative, there aren’t any contrast requirements when it comes to frontend development.

Focus, Role, & ARIA

The Angular, React, and Vue frameworks all provide support for the Accessible Rich Internet Applications (ARIA) toolkit.

ARIA is a set of attributes that define ways to make web content and web applications more accessible to people with disabilities. It provides the required functionality for assistive technologies — the ability to control input devices for people with limited or impaired motor functions and screen readers for people who have visual impairments.

ARIA can be used as an indicator of the state of a web component to a screen reader or an input device. In a web application, components indicate their current state visually. If the state of the component changes, the object’s presentation changes. For example, a checkbox indicates the values are true by displaying a checkmark, and false by leaving the box blank. To support assistive technologies, additional semantic information is required so that the component’s state can be presented to the user.

<input id="checkbox" type="checkbox" role="checkbox" aria-checked="true" />

In this example, to provide this information we may add the aria-checked label to the component. If the page is read by a screen reader, it will use a label to inform the user if the box is checked or not. If the page is being used by a person with limited mobility, component state changes can be indicated via haptic feedback.

Considering there is no HTML5 element for a progress bar, the example builds the element in a <div>, but by adding our ARIA tags, we can control SEO and accessibility while also indicating what this element is and give us ways to handle it. We may also add our tags and manipulate them via javascript if they are not directly on the HTML element.

<div id="percentage" role="progressbar" aria-valuenow="75" aria-valuemin="0" aria-valuemax="100"></div>

Thanks to javascript, we may target our elements and use getAttribute to retrieve a data or ARIA attribute. To change the values, you may use setAttribute. For dynamic elements, it is intrinsic to keep one element and use javascript to change the values in order to pass important information to either the user or SEO engines.

// Find the progress bar <div> in the DOM
var progressBar = document.getElementById("percentage");
 
// Set its ARIA roles and states so assistive technologies may know about the component with associated values and information
progressBar.setAttribute("role", "progressBar");
progressBar.setAttribute("aria-valuemin", 0);
progressBar.setAttribute("aria-valuemax", 100);
 
// Create a basic function that can be called at any time to update the value of the progress bar
function updateProgress(percentComplete) {
progressBar.setAttribute("aria-valuenow", percentComplete);
}

Accessible Interactive Content

Screen readers are a form of assistive technology that help users who are blind, visually impaired, illiterate, or have learning disabilities navigate the internet. They translate text into auditory or tactile output by reading it out loud or transmitting it to a braille keyboard. Screen readers don’t interpret styling they come across, so as developers, it’s important that we provide the necessary additional information through role and ARIA labels to help keep the screen reader — and inevitably our users — well informed.

In general, screen reader users set the speed high, and the verbosity low, so keep any screen reader text short and to the point. The role of a semantic element (like button or heading) is announced, so you don’t need to provide additional information about the use of those elements. Screen reader users require no more and no less information than visual users.

Keeping the accordions, tables, carousels, and dropdowns consistent with accessibility standards in line with typography, colors, and box shadow choices is just the icing on the cake. Major and minor elements should be considered when integrating accessibility into a project. Certain elements will allow alternate text and that should always be added, such as images and SVG. Without the basic alt tag, we rely on ARIA and role for screen readers and other devices that have accessibility tools.

Navigation

A website or web application usually has a standard navigation. There are also lower level navigation elements within larger components such as a subnavigation or within other elements such as a carousel or slider. ARIA plays an importan role here with aria-label and role allowing the user to focus, the developer to apply :focus styles, and SEO engines to process the element’s label and role.

It’s also good practice to keep track of tabindex down the page as part of the navigation plan with accessibility. The tab order will work on its own from top down automatically, but in complex cases you may issue them where needed to guide the user. A tabindex="-1" removes the focus from the user but allows it to still be targeted programmatically in the background.

Modal dialogs or overlay banners such as cookies and/or privacy prompts are other examples of where to apply the tab order. Overall the importance of good contrast, typography, color usage, and focusability dominate most areas of accessibility for frontend developers. This is most prevalent with the global navigation and equally important as the user navigates through the website or application with the keyboard. Colors and contrast come into play with horizontal dividers and other elements that do not require any ARIA labels, but do require visually impaired users to see divisions of content and move through it all properly with the keyboard.

Buttons vs. Links

Simply put, if it acts like a link, then it’s a link; if it acts like a button, then it’s a button. That’s it. Properly style and use anchor tags for links and buttons for buttons.

Error Handlers & Disabled Elements

As developers, we strive to make visually stunning and intuitive components and often times that means simplicity is key. Colors and symbols are all important, but as mentioned above, images, SVG elements, and generic semantic HTML does not convey much meaning with those elements alone when it comes to accessibility. Forms have come a long way in this regard with simplicity in frontend development and user interfaces and there are still hurdles when it comes to making them simple to navigate while remaining visually appealing.

Luckily, we can have the best of both worlds with ARIA labels and some javascript. Showing the user where they are missing information is important. Here is where just symbols and colors are not enough, but we can still use them with attributes. When a single label isn’t enough, you can use attributes like aria-labelledby or aria-describedby to connect multiple labels or inputs.

Anything that changes visually for the user — input field values or disabled buttons for example — should also be conveyed programmatically to indicate the roles, changed values, and labels for each element. Placeholders are new in HTML5 form elements and are very helpful, but we still should indicate it in an aria-label or other attribute that works for the element. Remember to carefully work with tabindex as well with an entire form, if it can be allowed, allow the form to tab down programmatically on its own without issuing a tab order and try to reserve them for very complex layouts.