Building Accessible Front-Ends

How You Can Make Your Site More Accessible for All Users, and Why it Matters

What is Accessibility?

Simply put, accessibility describes whether a product can be used by people of all abilities. We see these considerations all the time in the physical world; think about accessible parking and bathroom stalls, wheelchair ramps, braille or raised lettering- there are tons of examples! There are also considerations we have to make in the digital world, or our products will be inaccessible to people of some abilities. International standards for digital accessibility are defined by the Web Content Accessibility Guidelines (WCAG), which are linked in the resources at the end of this article.

Who Am I and Why Does Accessibility Matter to Me?

I’ve worked as a front-end developer at Capital One for just over two years. I’ve contributed to a number of products, both internally and customer facing, and I’ve learned that accessibility matters on all of them. I’ve also learned that anybody can be an ally in the cause of digital accessibility. It doesn’t matter if you’re on the product team, design team, or actually building a site; if you see something that’s not accessible, speak up!

This post will focus on accessibility in front-end development specifically. As front-end developers we need to design and develop with accessibility in mind, but what does this mean? Just by writing clean, correct HTML, you’re already doing a lot right; but there’s also a lot more you might not be thinking about.

Simplicity is Great, Sometimes

Let’s start out with an example before diving into best practices. As developers, we want our products to be beautiful and intuitive, and oftentimes that means we try to simplify them. For example, many designers rely on colors instead of words to communicate meaning. Think of a form with a field for entering an email address. If the email is invalid, we could signal to a user by highlighting the field in red. This seems intuitive, but not to a user who may be colorblind. Without additional information, the error message is completely lost and the form is inaccessible for those users.

Similarly, think about the number of icons you see in the products you use. In general, people will recognize that a magnifying glass means “search”. But again, this isn’t intuitive to users who may not be able to interpret or see it. The search field would be inaccessible for those users.

In this example, simplicity has a downside as it limits accessibility for some of our users. Let’s learn more about the best practices for building accessible front-ends.

Who Are We Developing For?

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, about 15% of the world’s population experiences some form of disability. As developers, the types of disabilities we need to keep in mind when we develop include auditory, cognitive, neurological, physical, and visual impairments. But accessibility doesn’t just help users with permanent disabilities, it can also help users with “temporary” or “situational” disabilities. Let’s go over these different definitions.

A permanent disability is permanent physical or mental condition that limits a person’s movements, senses, or activities. There are many examples of this, like blindness or low vision, deafness or low hearing, and many types of mobility impairments. Users with permanent disabilities often need some form of assistive technology, like a screen reader.

A temporary disability is a temporary physical impairment. For example, this could be a broken arm that keeps you from using your mouse with your dominant hand, or losing your glasses and needing a larger font size to read your screen.

A situational disability is an impairment due to your situation. For example, if you’re in bright sunlight and need to turn up the contrast on your screen, or if you’re on a noisy train and need captions on videos or audio you want to listen to.

At some point, all of us will be in at least one of these situations, so it’s vitally important that we account for them in development. This includes using sufficient contrast, responsive font sizes, clear navigation, and proper keyboard accessibility. Developing with accessibility in mind helps us ensure that anyone, in any situation, can still access our products. So how do we do that? Let’s talk about it.

Proper Styling and CSS

CSS can play a large role in how accessible your site is, especially for users who may have some sort of visual impairment, color blindness, or are in a situation like low lighting, or have a glare on their screen. It can also help users who are using different browsers or screen sizes.

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. Non-sighted and sighted users will both be able to tell what’s in the strong 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 non-sighted 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.

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 (which is at least 14pt and bold, or at least 18pt) can be slightly lower, at 3:1. If something is a logo, or purely decorative, there aren’t any contrast requirements.

Screen Readers

Screen readers are a form of assistive technology that helps users who are blind, visually impaired, illiterate, or have learning disabilities navigate the web. They translate text into auditory or tactile output by reading it out loud or transmitting it to a braille keyboard. Some screen readers also use the landmarks in a page to help users navigate and interpret page layout. Screen readers don’t interpret styling they come across, so as developers, it’s important that we provide the necessary additional information and avoid making mistakes that might confuse them.

In general, screen reader users set the speed high, and the verbosity (how much information is announced) 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.

Alt Text

All inline images should have alternative text, which can be provided in the “alt” property, and all images that contain information not already communicated in adjacent text require a non-null alt attribute. A screen reader will announce that it’s looking at an image and read the alt text. Don’t be repetitive (i.e. don’t write “image of flowers”) because the screen reader will already know it’s an image. Be descriptive enough to provide the context someone would get from the image (i.e. “The White House” instead of “a building”).

When to Skip Alt Text

If an image is purely decorative, or the information it provides is already labeled, you should include an alt attribute set to an empty string. This will cause a screen reader to skip over the image, instead of defaulting to reading out the entire source url.

ARIA Properties

Accessible Rich Internet Applications (ARIA) provide a set of attributes that includes roles, labels, and states that help us communicate semantic information to assistive technology. ARIA attributes make web content and applications more accessible. However, they should be used as a last resort, when native semantics are missing. ARIA attributes don’t work reliably on non-semantic elements, so if you use them, make sure you include any necessary roles. It’s also important to keep in mind that older software versions may not support all ARIA properties, so again, always favor semantic HTML elements where possible.

Buttons always need discernible text (text a screen reader can read). If you have an icon for a button (like an “X” to close a popup), you can provide discernible text by using an “aria-label” attribute.

Semantic HTML

I’ve mentioned semantic HTML a few times in this post; what does it mean? Semantic HTML is just HTML that has meaning, such as header tags. <h1> is the first header tag, it usually represents the title of the page or the most important information. Every page should have one <h1>. You should use other headers (<h2> thought <h6>) to structure the rest of the information on your page.

Sighted users can interpret a larger header as the title of a topic, and by using header tags instead of just styling, we can communicate that same information to our non-sighted users through screen readers.

We can also use semantic HTML to communicate layout and aid navigation, by using tags like <header>, <article>, <nav>, <section>, and <footer>. When we have to use non-semantic HTML, like <div>or <span>, we can provide the necessary context with aria-landmarks, like role=”navigation” or role=”main.”

Semantic HTML is the single best way to ensure accessibility of web pages. For more complex elements, you can refer to the WAI-ARIA Authoring Practices, linked in the resources below.

Forms

Forms can be a really tricky part of web development; there’s a lot of important information to communicate to your users. Forms should always be organized logically (left to right, top to bottom). All instructions, requirements, and errors should be clear. Form fields should all be clearly labeled.

As a side note, screen readers have a separate mode for forms, and will automatically switch when it encounters a form element. In form mode, a screen reader will skip any non-form elements, so keep them to a minimum.

Sighted users should be able to associate inputs with their labels visually. In the above example, because the label Email is next to the text box, it’s visually clear that the text box is for email. We can programmatically associate inputs with labels for users with visual impairments by adding a for attribute to the label and including the id of the input.

Sometimes, developers use placeholders as a substitute for labels. However, this can cause a lot of issues for accessibility. For one thing, the contrast often isn’t sufficient. In the above example, you can see the default placeholder text is a light gray, which is a little difficult to read. More importantly though, the information in a placeholder doesn’t persist when a user starts typing. This means users with memory impairments or other cognitive disabilities won’t be able to recall what the input they’re typing in is for. Think about how confusing it would be to start filling out a date, get halfway through, and realize you don’t remember if it was supposed to be the full year, or just the last two digits, and have to start over.

Placeholders aren’t wrong, they’re just not adequate replacements for labels. Make sure any important information persists, use a real <label> whenever you can (they’re supported by browsers and screen readers), and don’t forget aria attributes. When a single label isn’t enough, you can use attributes like aria-labelledby or aria-describedby to connect multiple labels or inputs.

Keyboard Users

Blind users, users with motor impairments, and users with tremors or difficulty with fine motor control all might rely on a keyboard instead of a mouse for navigation. Some users may have little or no use of their hands, so they may have modified keyboards or an assistive technology that mimics the functionality of a keyboard. Typically, tab is used to navigate, and focus indicators (by default, there’s usually a blue ring around the item in focus) are used to show what’s currently in focus. Tabbing only takes you to actionable elements, like links and buttons.

Navigation Order

The default navigation order of your site should be intuitive, which means you should try to match your source code to the page flow, so the user naturally moves from left to right, top to bottom. If necessary, you can add focus to items that aren’t actionable by default by using tabindex=0. Only actionable elements should be in the focus order; non-actionable elements are navigated with the virtual cursor.

tabindex=0 allows elements to receive keyboard focus in the order it appears on the page. If you add this to an element, make sure it actually is actionable, and users can activate it using Enter or Space.

Using tabindex=1 (or greater) explicitly defines a tabbing order. This is often a bad idea, because it takes priority over every other actionable item on the page, so be careful when using it. tabindex=-1 allows an item to receive focus programmatically, but a user cannot tab to it.

Links

A link with a non-null href will be in the focus order and respond to the keyboard, but a link without an href will not. Often, developers will add <a> tags with a non-null href, but they’ll forget to account for keyboard users when adding JavaScript functionality.

In this example, the menu is opened on mouseover, but a keyboard user can’t mouse over anything. You would need to add something for a focus event, or an Enter or Space keypress.

Because keyboard users can tab from link to link, links should make sense out of context. Specifically, link names like “Click here!” aren’t accessible. Additionally, sometimes sites have a lot of navigation links at the beginning of their sites before the main content, these can be tiresome to tab through. Providing a skip navigation link to skip to the main content can make the experience a lot smoother for keyboard users.

Media Accessibility

If you’re working on a site with a lot of media, make sure it’s accessible! For example, PDFs should have tags that screen readers can access, and audio and video should have captions. Even if you’re just uploading a video to Youtube or a meme to Facebook, check that the auto-generated captions and alt text are correct.

User Experience

Avoid creating experiences with important time sensitive content, like countdowns. Users might not be able to react or comprehend fast enough to take action. Use simple, clear, and concise language, so the greatest number of people can access and understand your content.

Testing

There are lots of ways to test your site. You can install accessibility auditors on Chrome to run checks for basic things, like that no two elements on your site have the same id. You can also turn on the default voiceover in your computer’s settings, or download an extension, to see what using a simple screen reader on your site is like and make sure all your images have alt text.

You should also test navigating your site as a keyboard user. You should be able to use tab to move forward and shift + tab to move backwards. Links should be accessible using Enter, and buttons should be accessible with Enter and Space. There’s lots of helpful guidelines for more complicated content, like checkboxes (you should be able to check them with Space), so be sure to look up the guidelines for whatever layout you’re using on your site.

Get Involved (#a11y)

Finally, one of the most important things you can do is just to get involved in the conversation. Follow accessibility hashtags (like #a11y on Twitter) and read about other people’s experiences. Speak up when you see opportunities to improve accessibility. Semantic HTML, assistive technologies, and accessibility requirements evolve all the time, so keep looking for new approaches and solutions. Always ask yourself, is this accessible to users of all abilities? And if it’s not, speak up.

Resources:

• Web Content Accessibility Guidelines (WCAG) 2.1 https://www.w3.org/TR/WCAG21/
• Understanding WCAG 2.1 https://www.w3.org/WAI/WCAG21/Understanding/
• W3C Accessibility Overview https://www.w3.org/standards/webdesign/accessibility
• WCAG checklist: https://webaim.org/standards/wcag/checklist
• World Health Report https://www.who.int/disabilities/world_report/2011/report/en/
• WAI-ARIA Authoring Practices: https://www.w3.org/TR/wai-aria-practices-1.1/
• WebAIM email discussion list: https://webaim.org/discussion/
• Contrast Checker https://developer.paciellogroup.com/resources/contrastanalyser/
• Online Contrast Checker https://app.contrast-finder.org
• Attest https://www.deque.com/tools/worldspace-attest/

DISCLOSURE STATEMENT: © 2019 Capital One. Opinions are those of the individual author. Unless noted otherwise in this post, Capital One is not affiliated with, nor endorsed by, any of the companies mentioned. All trademarks and other intellectual property used or displayed are property of their respective owners.