While the Front End Development Team takes care of most of the accessibility setup, once the initial Pattern Library and Layout Guide are complete, it’s off to the end development team to build out the real, live pages.

To make sure we’re all taking Accessibility into account while building pages, in sync, we’ve created this section, which outlines only the most common pieces of Accessibility. Why only the most common? There are literally hundreds of different pieces that can be applied for keyboard and screen reading users, most of which will be irrelevant to you. But since you’ll be dealing with the bulk of the development, the below items are things you’ll more than likely run into through the project life.

Semantic Markup

Anchors are an extremely important element to semantic markup. All too often we end up creating markup with interactivity in mind, which can severely impact usability. Have you ever bound click handlers to elements like list items or divs? This is exactly the issue. Anchor tags [and buttons] are meant to signify clickable behavior so please be sure to semantically mark up your components before interactivity ever comes into play.

Description of Table

A mandatory part of WCAG 2.0 and screen reader accessibility is providing caption elements on every table in a site. The caption element is used to provide the end user additional information about the table they might otherwise not get. If your designs don’t take a caption element into consideration, fear not, we can use specialized classes to hide the element from standard view (see the Classes section).

It’s common to provide additional content or information to an accessibility enabled user. Most of the time this means creating additional elements on the page which cannot be visually seen but can be picked up and read by the screen reader. Simply setting a display to none or hidden visibility won’t do the trick so we have a screen reader specific class to handle this. Add .sr-only to any element to consume the hidden styles which keeping the content readable for those who benefit from the additional information.

Html Attributes


Pretty strait forward but it’s a good idea to supply additional information about a link in the form of a title attribute when the innerHTML doesn’t give much of an idea on where the link may go.

TODO: Add alternate text

Another very well-known but ignored feature is the alt attribute. It’s important to give alternative text to images, especially if the image does not have tabular data associated with it, so the sighted user understands what they are working though.

Html Roles

The presentation role is used to describe presentation only elements. The screen reader will essentially ignore the element. Presentation is great for things like icons or table cells with no data – anything used for visual presentation.

The button role is another handy role which tells the screen reader we are dealing with a button, despite what the element actually is. This is great for links that do not go to another page such as opening a modal or clicking through tabs – interactive elements.

Like the new[ish] html nav options, aria comes with the ability to let the user know they are navigating though tabs using the tablist/tab roles. Tabs, like buttons, indicate the user can tab through sections of content rather than page jump as a natural link would. The difference is that the tab role allows association between a group of tabs and its tablist.

Aria API


Set the aria-controls attribute to an elements id when you want to link one element to another in the scenario you are building interactivity. So in the example below we are linking association between a button and content it will expand.

Adding onto aria-controls, it’s helpful to provide more information to screen readers. In the below example, we are telling the screen reader the div content is hidden and the button is not expanding any content. These attributes do not have to be used together and don’t just fit into the case of expanding/collapsing content. You can use aria-hidden for any kind of element like modals, popups, or off screen elements.

Saved Screens

Detailed description...

Use aria-describedby to associate additional content to an element. For instance, we have a link that really doesn’t give much information as to what it does. We can add a “helper” element and link its additional text content to the link, which will be read off to the user but not necessarily seen by our visual users.

First Name

Enter your first name...

Aria-labelledby works identically to describedby in most cases except with form elements. The labelledby property acts as a label element, whereas describedby works the same. The label will be read before the describedby element. Most of the time, we’ll be providing a label element, so this attribute becomes unnecessary.


When updating dynamic content, it’s sometimes important to let the user know what content updated, and allow the screen reader to jump to that part of the document in order to begin reading the new, refreshed data. Aria-live accomplishes this and can be set to “off,” “polite,” or “assertive.” Polite lets the screen reader finish what it’s doing (maybe reading some other paragraph) while assertive stops all reading and goes to the new, live content.