0

Lets say I have following HTML markup:

<a class="btn btn-primary" data-toggle="collapse" href="#collapseExample" role="button" aria-expanded="false" aria-controls="collapseExample">
Link with href

and I don't want to user the attributes like aria-expanded="false" aria-controls="collapseExample", but want this anchor tag to be accessible, how can I achieve this and is it good practice to avoid aria-* attributes.

Heretic Monkey
  • 11,687
  • 7
  • 53
  • 122
Vikrant Kumar
  • 100
  • 8
  • 1
    You are going to have to provide a more complete example to know what you are trying to build, at the moment the above HTML makes no sense on it's own as you have `href` `role="button"` etc. which all conflict with each other. Do you want to post a full example of what the above is trying to achieve (an example that works with basic JS functionality if needed and styling) with the associated section it is expanding (which is what it appears to be, an expanding section??, but it is hard to tell) so that we can help you structure it correctly. But immediately ` – GrahamTheDev Feb 22 '21 at 07:46
  • I'm guessing the authors of WAI-ARIA would say it is not good practice to avoid the aria-* attributes... – Heretic Monkey Sep 05 '21 at 20:54

2 Answers2

0

If you are using a native anchor tag with an href, it should already be accessible (screen readers will interpret it as a link and it should be clickable using assistive technology).

You will probably want to label the anchor tag to give it a more user-friendly name/description which you can accomplish using an aria-label. Alternatively, you may be able to use an aria-labelledby tag that points to the Id of a HTML element whose inner HTML provides the label for the anchor tag, although it sounds like an aria-label would suit your use case more appropriately. See aria-label docs here: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_aria-label_attribute

Using aria tags is definitely best practice in a lot of cases if you’re trying to build accessible software, although you need to use the right aria tags in the right scenarios. For example, aria-expanded should be used with an expandable/collapsible menu button instead of something like an anchor tag.

bad_coder
  • 11,289
  • 20
  • 44
  • 72
Garret Patten
  • 16
  • 4
0

There isn't a native HTML way to indicate an expandable/collapsable element so you have to use ARIA.

The first rule of ARIA says if there's a native HTML way to achieve your results, then use HTML. If there's not, then ARIA is the next best thing. ARIA isn't inherently bad but treat it like salt. A little ARIA adds a nice flavor but too much ARIA ruins the app.

In this case, aria-expanded is the best way to represent an expandable section.

If you really didn't want an ARIA attribute, you could have visually hidden text that describes the element as "expanded" or "collapsed". I would not recommend this approach because aria-expanded has better built in accessibility support. When you change the value of aria-expanded, the screen reader will automatically announce the state change "for free". You don't have to do anything. If you have visually hidden text instead, you'd be responsible for changing the hidden text when the state changes and you'd have to make the announcement for the screen reader (typically with aria-live).

It's a lot of work to not use aria-expanded.

Regarding aria-controls, unfortunately, that attribute doesn't buy you much. It's semantically correct to use it but most screen readers don't really do anything with it. For fun, check this out - https://heydonworks.com/article/aria-controls-is-poop/

slugolicious
  • 15,824
  • 2
  • 29
  • 43