# Best practices for launchpad accessibility

To best utilize the store launchpads for your customers, we recommend some best practices for accessibility.

Making your website accessible ensures it can be used by a larger, more diverse audience and improves the user experience for all your customers. In turn, this can also enhance your brand reputation and improve your search engine optimization (SEO) metrics.

These best practices provide practical guidance and examples to help you build accessible digital commerce experiences with the Store Launchpad for B2B Manufacturing or the Store Launchpad for B2C Retail. The store launchpad codebases target [Web Content Accessibility Guidelines (WCAG) 2.2 level AA](https://www.w3.org/TR/WCAG22/) as its foundation for web and digital accessibility. We recommend familiarizing yourself with the [WCAG principles of accessibility](https://www.w3.org/WAI/WCAG22/Understanding/intro#understanding-the-four-principles-of-accessibility).

It is your responsibility to ensure ongoing compliance with accessibility regulations in the respective countries that you operate.

When using or amending the store launchpad codebase, remember the following accessibility best practices.

## Give pages informative titles

Missing or uninformative titles in HTML pages can hinder navigation for your customers who rely on assistive technologies such as screen readers. Make sure all HTML pages have a `<title>` element with useful text that reflects the content of the page.

For example, the default title of the Orders page of the B2B Store Launchpad for Manufacturing is:

```html
<title>Orders - The B2B Store</title>
```

## Make sure button labels match

Mismatched labels between the visible button text and the `aria-label` text can confuse your customers using alternative means to navigate your site. The `aria-label` is an HTML attribute used to define a label for screen readers and other assistive technologies. You should ensure that the `aria-label` matches or includes the visible button label.

For example, for the following button, a screen reader announces **Find** while customers see **Search**.

```html
<button aria-label="Find">Search</button>
```

Instead, the accessible name should match or include the visible label for consistency and to support voice command users. For example:

```html
<button aria-label="Search">Search</button>
```

Or alternatively:

```html
<button aria-label="Search the website">Search</button>
```

## Describe icon buttons

Icons that are clickable buttons but don't have accompanying text can be confusing for screen readers. When possible, use buttons with visible text. For example:

```html
<button className="bg-blue-500 text-white px-4 py-2">Close</button>
```

However, when that is not possible and you must use an icon to represent the button text instead, you should ensure all icon buttons have an `aria-label` that represents what the button does so that screen readers can announce this to their users.

The following is an example of the code for an inaccessible icon button:

```html
<button onClick="{handleClear}">
  <CloseIcon className="w-5 fill-gray-600 stroke-0" />
</button>
```

By adding the `aria-label`, the button becomes more accessible. For example, the following icon button is for an icon that closes a pop-up dialog:

```html
<button aria-label="Close">
  <CloseIcon className="w-5 fill-gray-600 stroke-0" />
</button>
```

## Give links discernible text

To ensure your links are accessible, they should have either visible text or an `aria-label` to describe what the link is for screen readers. For example:

```html
<Link aria-label="My Account" href={accountLink.href}>
  <UserCircleIcon className="w-6 text-gray-700 lg:w-5" />
</Link>
```

## Make sure all input fields have labels

Fields that require a user to enter text or other data must have descriptive labels to ensure the user understands the purpose of the field and so that screen readers can read the text.

To add a label for an input field, use the HTML `<label>` element. For example:

```html
<label htmlFor="email">Email Address</label>
<input type="email" id="email" name="email" required />
```

If you cannot use a visible label, use the `aria-label` or the `aria-labelledby` element instead. For example:

```html
<input type="text" aria-label="Search" placeholder="Search..." />
```

## Allow navigation by keyboard

Some customers cannot use a mouse, therefore, to ensure your website is accessible, customers should be able to navigate and interact with your site [using only their keyboard](https://webaim.org/techniques/keyboard/#testing). You can use the `tabindex` element to make sure the keyboard can focus on a particular element. For example:

```html
<button
  tabindex="{0}"
  onClick="{onClick}"
  className="{categoryClassNames}"
></button>
```

Additionally, you can provide keyboard shortcuts for specific components by using the `aria-keyshortcuts` element. This lets assistive technologies communicate these shortcuts to their users, thus making navigating your website easier and more efficient. For example:

```html
<div
  role="button"
  tabindex="0"
  aria-keyshortcuts="Alt+S"
  onclick="submitForm()"
>
  Submit
</div>
```

Customers must also be able to navigate tables on your website using screen readers and keyboards. To allow this, make sure you use the `<table>` element with the `<th>` attribute for headers and implement ARIA attributes for pagination. For example:

```html
<button aria-label="Previous page" onClick="{onPrevious}">Previous</button>
```

## Give clickable components a minimum touch target size

Small clickable elements can be difficult to interact with, especially on touch devices. All clickable components on your website should have a minimum touch target size of 24x24px. This reduces the chances of accidentally clicking the wrong component, which improves accessibility and user experience. For example:

```html
<Link className="p-2" href={href}>{name}</Link>
```

## Consider the accessibility of styled components

Custom-styled components that use `<div>`, `<span>`, or other non-semantic HTML elements may not be accessible to customers who rely on screen readers or solely on keyboards. To improve accessibility, you can do the following:

- Assign the appropriate ARIA roles to mimic HTML elements, such as `role="combobox"` for a styled dropdown or `role="radio"` for a custom radio button.
- Enable keyboard navigation that uses the `Tab` and `Arrow` keys for moving focus across the page, and `Enter` or `Space` for selecting the relevant elements.

The following example shows a custom-styled combobox that uses the ARIA role element:

```html
<div
  role="combobox"
  aria-haspopup="listbox"
  aria-expanded="false"
  tabindex="0"
  onKeyDown="handleKeyDown"
>
  <span>Select an option</span>
  <div role="listbox" tabindex="-1">
    <div role="option" tabindex="0">Option 1</div>
    <div role="option" tabindex="0">Option 2</div>
  </div>
</div>
```

For custom checkboxes and radio buttons, use the `role="checkbox"` or `role="radio"` ARIA role element. Use the `aria-checked` attribute to manage if the user has selected the checkbox or button. For example:

```html
<label role="checkbox" tabindex="0" aria-checked="false">
  <span class="checkbox-icon"></span> Accept Terms
</label>
```

## Use the logical heading structures

Content that doesn't use a [logical structure](https://webaim.org/techniques/semanticstructure/) can be difficult to navigate for screen reader users and can prevent all users from customizing the display of information effectively, while also negatively impacting SEO.

Headings should be used to create a clear, logical outline of your content with concise, descriptive text that lets users scan it easily.

To ensure that your website uses the correct heading structure, use the HTML heading tags of `<h1>` to `<h6>` in a hierarchical order. The `<h1>` tag should indicate the main title of the page and therefore typically is only used only once per page. Subsequent headings (`<h2>` to `<h6>`) should be used for subheadings, sections, and subsections within the content.

Avoid skipping heading levels, for example, using a `<h2>` followed by a `<h4>` for the next section, and don't use headings for purely stylistic purposes.

Use a CSS text style scheme for styling, such as `large-title`, `medium-title`, or `small-title`.

An example of a hierarchical content structure using HTML header tags is as follows:

```html
<h1>Main Page Title</h1>

<h2>Section 1</h2>

<p>Content for section 1.</p>

<h3>Subsection 1.1</h3>

<p>Content for subsection 1.1.</p>

<h3>Subsection 1.2</h3>

<p>Content for subsection 1.2.</p>

<h2>Section 2</h2>

<p>Content for section 2.</p>
```

## Use the minimum recommended contrast ratios

Insufficient contrast between text and background makes content difficult to read for users with visual impairments, such as those with low vision or color blindness. While contrast requirements may vary based on the design and color scheme of your website, aim to follow WCAG guidelines and maintain a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text.

To ensure your site meets these requirements, consider doing the following:

- Test color contrast against your site's specific design.
- Use [accessibility testing tools](/frontend-development/launchpad-accessibility.md#test-the-accessibility-of-your-site) to verify contrast levels.

## Test the accessibility of your site

Use the following tools during your design stage to assess how accessible your website is:

- [**Accessibility Insights**](https://wave.webaim.org/extension/): for automated testing against WCAG guidelines and checks for keyboard and screen reader support.
- [**WebAIM Contrast Checker**](https://webaim.org/resources/contrastchecker/): for checking that text and background contrast is compliant with WCAG standards.

Use the following tools during your development stage to test the accessibility of your site:

- [**WAVE Web Accessibility Evaluation Tool browser extension**](https://wave.webaim.org/extension/): a browser extension that highlights contrast issues, missing alt text, and ARIA errors.
- [**Axe Accessibility Scanner**](https://developer.chrome.com/docs/lighthouse/overview): a tool that integrates into development workflows to provide you with detailed accessibility reports.
- [**Google Lighthouse**](https://developer.chrome.com/docs/lighthouse/overview): a tool that assesses contrast levels, keyboard navigation, and screen reader compatibility.

## Related pages

- [Area overview page with navigation](/frontend-development.md)
- [Previous page: Overview](/frontend-development/launchpad-overview.md)
- [Next page: Best practices for performance](/frontend-development/launchpad-performance.md)