- Daria Darma
Image by vectorjuice on Freepik
Accessibility (a11y) is an important consideration in many areas, including technology and web development. Imagine if you have a website and a part of users might have no clue what it is about. What is the purpose of this website?
This article highlights some of the a11y tips while developing a web page.
Have you seen this transportation accessibility bug? Imagine a blind person trying to press the correct button.
The Braille on the Alarm and Stop buttons are the same. Image from Reddit by YaBoiJasper.
Unfortunately, the same situation can happen with web content. So, let’s make our pages accessible to end users.
All customers regardless of their physical condition should be able to understand a website’s content and interact with it. There are many kinds of screens: phone, TV, computer, car, refrigerator, watch, and other devices. We do care about accessibility in DNB, and I want to mention some points that I take into consideration while developing.
People must be able to:
- find a website
- use it with any kind of device
- understand and interact with it.
As developers, we have Web Content Accessibility Guidelines (WCAG) to make our web content more accessible for people with disabilities. I am not going to go through all of them, rather highlighting several tips to keep in mind.
Want to work with us? Avaliable tech positions in DNB
Tip 1. Headings as examples of semantic HTML. Structure with headers.
Headings indicate the text importance and arrangement. Screen readers and search engines can provide more meaningful experiences to users by understanding the correct structure.
For instance, we have headings from H1 to H6. H1 is used for the most important information, it should describe the main topic of a page.
<h1>Heading level 1</h1>
<h2>Heading level 2</h2>
<h3>Heading level 3</h3>
…
<h6>Heading level 6</h6>`
Users can browse a website through the level of headings. It is essential to use the headings in the correct way.
Recommendations:
- Use only one heading level 1 per page. It can be a page title and it should be the only content with an H1 tag.
- Don’t use headings for styling purposes. Use classes if needed. If you are asked by the UX team to style some text the same way as the page title, you should provide the relevant heading level regardless of how it looks.
- Don’t skip heading levels. If you used H1 for the title, use H2 for the subtitle. If you used H2 for the title, use H3 for the subtitle and so on.
As a team, we are using a Heading Component from DNB’s Eufemia design library as a helper to create automated semantic headings within a boundary of the web heading rules.
We have a Rich text editor with automated increasing heading levels in our Content Management System so that editors automatically use the correct heading levels.
Examples:
Imagine a page as a list of sections (horizontal blocks). The first section is Page title with an H1 tag. The second section might contain an optional title and a mandatory text block. If the title is present, it should have an H2 tag, and the text headings should be tagged as H3. If the title is not there, the text headings become H2.
Example 1. The optional section title is not set:
Here are code examples for this use case:
const HeadingIncreaseWrapper = sectionTitle ? HeadingIncrease : React.Fragment
...
{!!sectionTitle && (
<OptionalTextSectionHeader>{sectionTitle}</OptionalTextSectionHeader>
)}
<HeadingIncreaseWrapper>
<TextComponent value={content} />
</HeadingIncreaseWrapper>
Tip 2. Use aria-label attribute if needed.
The sectioning element attribute is a string that is read by screen readers to provide information about the purpose of the element.
Let’s consider a bad example below:
<header>
<nav>...</nav>
<nav>...</nav>
</header>
<main></main>
<footer>
<nav>...</nav>
</footer>
Respective landmarks would be:
banner
navigation
navigation
main
content information
navigation
So, there are three navigations, and it is impossible to distinguish them.
For this use case, it is recommended to use aria-labels to give meanings to the elements. Much better example would look like this:
<header>
<nav aria-label=”main”>...</nav>
<nav aria-label=”breadcrumbs”>...</nav>
</header>
<main></main>
<footer>
<nav aria-label=”footer links”>...</nav>
</footer>
The landmarks would be:
banner
main navigation
breadcrumbs navigation
main
content information
footer links navigation
You can find another good example of using an aria-label attribute on store.apple.com
Open developer tools and search for <nav:
<nav id="ac-globalnav" role="navigation" aria-label="Global".....>
…
</nav>
<nav class="as-globalfooter-breadcrumbs" aria-label="Breadcrumbs" role="navigation">
…
</nav>
<nav role="navigation" aria-label="More Apple Store Links" class="as-globalfooter-directory with-5-columns">
…
</nav>
Tip 3. Use native Html elements and attributes first.
The good practice is to keep the native semantics of HTML elements. If it is possible to not use aria, do it.
<!-- don't do it-->
<span role="button" onClick="submitSmth();">Submit</span>
<!-- do it-->
<button type="submit" onClick="submitSmth();">Submit</button>
Tip 4. Check keyboard focus.
All interactive controls must be able to receive keyboard focus. You can do it with tabindex.
- "0" will insert an element into the tab order (natural)
- "- 1" will remove the element from the natural tab order
- "> 0" will allow the element to move to the front of the natural tab order
Example with tabindex="-1"
<a href="#main-content" id="skip-link">Skip to main content</a>
<nav>
...
</nav>
<main id="main-content" tabindex="-1">
...
</main>
Now we can move focus to the main content:
document.getElementById('skip-link').onclick = function(e) {
e.preventDefault();
document.getElementById('main-content').focus();
}
For things that must be focusable role="presentation" or aria-hidden="true" should never be used. If it is, the button will be hidden from screen readers and keyboard navigation.
<!-- don’t do it -->
<button role=”presentation”>Submit</button>
<button aria-hidden=”true”>Submit</button>
<div aria-hidden=”true”>
<button>Submit</button>
</div>
Tip 5. Assign accessible names to elements.
<!-- don’t do it, the screen reader will read it as “input” -->
Search: <input type=”text”/>
<!-- do it, the screen reader will read it as “input search” -->
Search: <input type="text" id="search" aria-label="search"/>
<!-- do it, even better option. The screen reader will read it as “input search” -->
<label for="search">Search:</label>
<input type="search" id="search" name="search">
Tip 6. “Read more” links.
As an editor, provide clear and descriptive labels to links.
Example: Imagine that a person opens a screen reader and navigates through a text section with several “Read more” links. The person has no idea what to select if they want to read more about a specific part. As a better alternative, some context should be provided, for example, "Read more about our working hours".
As a developer, you can provide additional information for screen reader users without compromising visual content. It can be achieved using aria-label.
<!-- don't do it-->
<a href=”/”>Read more</a>
<!-- do it-->
<a href=”/” aria-label="Read more about DNB">Read more</a>
When screen readers discover an aria-label in the link code, its value is read (Read more about DNB) instead of the anchor text (Read more).
Tip 7. “Live regions” for dynamic content.
A "live region" refers to an area of a webpage that is intended to update dynamically, without requiring the page to be reloaded. Live regions are typically used to present information that changes frequently or in real time. To allow screen reader users to keep track of the changes the following could be done:
<div role=”region” aria-live=”polite”></div>
<div role=”region” aria-live=”assertive”></div>
If you are doing some calculations or showing search results a screen reader user can be notified that something changed on a page.
Aria-live can announce changes immediately or after a current reading is finished: polite waits for what is being read and assertive comes straight to the update.
It is nice to keep in mind that live regions should not be overused. Only use them if necessary, otherwise, the content is hard to listen to.