We hear the word “accessible” a lot concerning web design, but I wonder if people fully grasp what it means. When digital content is said to be “accessible,” it means that the information can be accessed and used as comparably by individuals who have disabilities as those who do not. This concept is more profound than it might seem at first.

For commercial organizations, building accessible content maximizes a site’s market reach. According to the World Wide Web Consortium (W3C), the global market of people with disabilities is more than 1 billion people with a spending power of more than $6 trillion.

Digital accessibility is included in the contract requirements in much of the work CGI Federal does for U.S. federal agencies. As a result, we often have the chance to collaborate with delivery teams to create inclusive web designs that meet the needs and preferences of a diverse group of users. Sometimes, these designs include complex layouts or user interface (UI) components for which there is not an agreed upon web standard.

In the past year, a navigational approach using so-called “cards” seems to have appeared everywhere in new web designs. In a web-based user interface, a card visually groups multiple elements (e.g., text, graphics, and interactive controls) on a topic into a single unit. By organizing content and available actions into a consistent card layout, designers strive to help users more easily scan and find the content they need. At the same time, card layouts can vary significantly based on the content they contain. For example, a product card for a commercial retailer’s website may look quite different from an article card on an agency’s news page.

As popular as they are, however, there is no collectively agreed upon best practice for creating accessible cards within the W3C Web Accessibility Initiative’s Accessible Rich Internet Applications (ARIA) Authoring Practices Guide. As a result, it may be difficult to determine what approach to use when coding new card design.

Beth Whitmer demonstrates how HTML in cards affects screen readers.

A proposed approach

Members of CGI Federal’s Human Factors Practice (HFP) collaborated to draft a card model that designers and developers could reference to create accessible card components in their web-based UIs. This involves a three-step process:

1. Decide whether the content represents a card.

2. Choose the right card container.

3. Determine whether multiple cards should be grouped into a card collection.

Determining whether the content you are building actually represents a card is usually—though not always--straightforward. In general, we’ve determined that content containing multiple elements (e.g. text, images, links, buttons, etc.) that are visually grouped and all relate to one common subject should be coded within a card component.

Second, and perhaps most importantly, you must choose the right container for the card, based on the content of the card. Here are our recommendations:

  • Does the content include a heading AND is it a type of content, such as a news article or blog post, that is independent of the context? That is, would the content be just as useful on another web page, in an email, or in printed form? If so, use an <article> element.
  • Does the content contain a heading, but the content is dependent on its context to be meaningful and understandable? Use a <section> element, which identifies it as a sub-section on the page.
  • Does the content have no heading? Then use a <div> element, which does not list it separately in the document’s outline.

Why it matters

Selecting the correct container element is allows people with visual disabilities who use screen reader software to read and interact with digital content. Screen reader software is a type of assistive technology that converts the text of a web page to synthesized speech and/or braille output. For many screen readers, the presence of the <article> or <section> element is announced when the user first navigates to it, which helps the user to comprehend the type of content that is contained within. Think of it as the auditory equivalent of the visual cues that white space and column divisions provide.

Developers should also use the aria-labelledby attribute within the <article> or <section> element, which some screen readers need in order to properly identify those elements it needs to announce.

Finally, you must determine whether multiple cards should be grouped into a “card collection.” In general, if multiple cards should be reviewed together, then we recommend using unordered list markup (<ul>) to group the cards into a list.

Find out more

My colleague Pavani Gonuguntla and I presented on cards accessibility at the 34th annual CSUN Assistive Technology Conference. The three working web-based demos and the PowerPoint slides from our CSUN presentation can be found here. Special thanks to front-end developer Kerry Chin for developing the demos and Human Factors Practice Director Jennifer Gauvreau for all of her input into the presentation!

About this author

Elizabeth Whitmer

Elizabeth Whitmer


Elizabeth Whitmer, a director in CGI Federal’s Health and Compliance Programs (HCP) business, is a digital accessibility professional who has served the public sector since 2008.