The choice of accessible Web application (ARIA)

This article is edited in Markdown, and the translations are published in the translation

Choice of accessible Web applications (ARIA)

Making the site accessible to everyone is a pretty tough job, especially in the days when we use custom tagging solutions (named Markup Solutions). I'm glad that the topic of #a11y(accessible abbreviation) has recently gained more and more attention because #a11y is nothing good, but just as James Williamson 's Twitter released today:

Our biggest misconception about improving accessibility is that it's helping others, but you're wrong, and that's your job. (The biggest misconception about accessibility is, and adding it you ' re doing somebody a favor. You're not a, you ' re doing your job.)

To make your site more accessible, you can use the Wai-aria (accessible Web App) to provide more semantic information to support access to assistive technologies.

The idea behind Wai-aria is great, but unfortunately it can be difficult to use beyond imagination. I recently encountered an example of a paging widget (pagination component), and I found a common error in it, and I want to discuss some of the relevant details in this article.

How Not (! ) to use aria-selected

So let's take a look at the following example:

<nav role="navigation" aria-label="Pagination Navigation">  <ul>    <li>      <a href="/page-1" aria-label="Go to Page 1">1</a>    </li>    <li>      <a href="/page-2" aria-label="Current Page, Page 2"         aria-selected="true">2</a>    </li>    <li>      <a href="/page-3" aria-label="Go to Page 3">3</a>    </li>  </ul></nav>

Many of the elements in this example are aria-label appropriately labeled with attributes. This is a good thing, because a link if it contains only a few digits, it cannot provide enough information to the blind. For the blind, it is hard for them to understand the meaning behind the digital link.

I would like to analyze this second link in depth. It has one that is aria-selected set true to. This is a flaw in aria ————— it can easily be mistaken. When you want to mark the correct page as selected, it seems to make sense, but in fact it doesn't work for a screen reader like VoiceOver .

In order to understand why this is not possible, we need to understand the concept of role in ARIA.

"Link" in Aria and its meaning

The Wai-aria role model is a way to provide assistive technology with information about how to handle a given element.

In our case, we're working with an anchor element (anchor), and the browser automatically associates it with "link." Standard HTML elements usually have the correct role associations. Browsers know what these elements mean and can treat them in the best and most convenient way.

Standard HTML elements can be presented to include appropriate focus processing, responses to keyboard and click interactions.

Standard tags are accessible by default.

So, let's look at the definition of "link":

An interactive reference to an internal or external resource that, when clicked, causes the user agent to navigate to the resource. (an interactive reference to a internal or external resource, when activated, causes the user agent to navigate to T Hat resource.)

There may be nothing new in this definition for you, but on the right side you will find information about the state of support and performance, which is usually set by HTML attributes.

Using these you can provide additional information to assistive technologies. The definition of "link" lists a series of ARIA attributes that you can use like aria-label , aria-hidden or aria-disabled so on.

aria-selectedis not in it.

So what is the right way to use it? Let's look at its specifications together.

aria-selectedThe meaning

aria-selectedThe definitions include:

This property is used for single and multi-select parts. (this attribute was used with single-selection and multiple-selection widgets.)

So aria-selected there must be some choices about use.

When I was working on the selection, I first thought of the selection element and the radio button. Links, on the other hand, do not provide any selection interaction.

In fact, some links within the "pagination Navigation" (pager) are not effective in this example. When you click on one of the links is usually loaded next page, in this case, here the pagination does not really choose the interaction.

aria-selectedThe actual use case

aria-selectedSupport a lot of role, including "tab", which may be new to you, but you I bet you know what you expect from it. If you look at this example you will see the use of "tab" and the aria-selected exact reasoning behind it.

<ul class="tablist" role="tablist">   <li id="tab1" class="tab" aria-controls="panel1"      aria-selected="true" role="tab" tabindex="0">Prices</li>   <li id="tab2" class="tab" aria-controls="panel2"      role="tab" aria-selected="false" tabindex="0">Features</li> </ul>

This example shows a tab component, which consists of many list items that control what is visible. The list itself has a role of "tablist", and each list item has "tab" to ensure that assistive technology knows what to do with it.

List items can respond to clicks and keyboard navigation in a focused state. This is through tabindex as well as a little JavaScript. This component is generally accessible, and in order to provide the user with additional information about which tab is currently selected, each tab aria-selected property is set. Screen readers are now able to identify "selected" because they can understand the tab property of an element.

There's more to it, and I'm not going to go into it here (you can find an explanation in this example), but the accessibility of the tag is not as trivial as it seems at first glance.

To remember the most important thing, you aria-selected can give the choice to interact with additional information like the current tag in this example.

Developer tools to rescue

As you can see, dealing with Wai_aria is tricky, but fortunately there are many solutions. For example, Google offers a very beautiful chrome extension, which can help you find such errors. To check your site, you can easily run an accessibility audit in the developer tools.

In addition to accessibility audits, this extension also expands element checking through accessibility panels. There you can take a look at the properties of the app, the role, and see how the assistive technology reads out the element aloud. It really helps, actually I often use it.

Summarize

Accessibility can be cumbersome to handle, but we have to read the Wai_aria rule values, and after using the right tools, I think we can make the site more accessible.

I hope you can enjoy this article, if you have any questions welcome you can tell me.

Edit

As a result, the correct property for the current page example in the paging is the aria-current attribute defined in Waiaria 1.1. Unfortunately, it was not well supported when it was written.

The choice of accessible Web application (ARIA)