Accessibility : harmful live-region usage

[blokche]

I was considering using barba.js for projects but I'm a bit disapointed with the usage of the aria-live region set on the wrapper element. It was a good intention but to me it's more harmful than helpful as it is implemented.

SPA navigation are often a bit challenging for assistive technologies users but some patterns have been tested with real users. Live regions can be useful but you don't want the whole document to be read aloud by assistive technologies. Only a page title should be announed in those elements.

The focus may be moved too, but I guess it's more the responsability of the developer to listen for page transition event and do the right choice for its use case. The documentation may help to build appropriate patterns, without forcing an opiniated behavior.

[xavierfoucrier]

Hi @blokche,

Sorry but we are not managing any aria-live attribute on the wrapper element.
This is the responsibility of the developer to manager addition work.

Barba JS is here to give you page transition power, we are aware of SEO concerns but the library doesn't manage any additional SEO stuff / attributes, you need to do it yourself.

Thanks for highlighting.

[blokche]

Hi. Thanks for your answer. Forgive my insistence but what about this line (186) in packages/core/src/core.ts:
this._wrapper.setAttribute('aria-live', 'polite'); // A11y

[xavierfoucrier]

Hi @blokche,

I am not an expert in WAI.
https://www.w3.org/TR/wai-aria/#aria-live

May be @thierrymichel can add further / additional informations to my post.

Anyway, if you feel that it's not good to use Barba JS library for your project, then feel free to use another one ✌️

[daun]

Setting aria-live on the wrapper should be avoided since it will read out the entire page on every visit. The ideal solution would be to announce page visits with a live region (e.g. Navigated to new page: {page title}) and then focus the new content container. I'd prefer if barba left it up to its users to implement a11y requirements; however you can just as easily remove the aria-live attribute in a hook:

barba.hooks.ready(() => {
  const wrapper = barba.dom.getWrapper()
  wrapper.removeAttribute('aria-live')
})

[brettburwell]

+1 for everything @daun added.

@xavierfoucrier I believe you may have misunderstood @blokche's original note. @blokche, please correct me if I'm wrong, but I don't believe you were asking for Barba to do more, but instead hoping for Barba to actually do less.

Currently, Barba automatically applies a aria-live="polite" to the wrapping element. I'm sure the intentions behind this are good, but in practice, it's a bad user experience for anyone with voice over technology on—as it reads out the contents of the entire wrapper every time Barba loads a new page.

@daun's suggestion is a good one. It's a simple way to remove the aria-live attribute that Barba adds. But it honestly feels a little silly that it's even necessary. It'd be nice if there was a configuration option that controlled whether or not that attribute is added (or better yet, if that bit code was removed entirely, as it's hard to imagine a scenario where anyone benefits from it).

I understand that A11Y stuff can be really challenging and issues don't always have a single, obvious solution. But I think this issue is worth reopening and reconsidering.

[xavierfoucrier]

@blokche @daun @brettburwell Hi guys!

Small update, I am now considering this as a bug fix, since it's not a good implementation with most assistive technologies.
I also +1 for what @daun said, announcing page title should be enough.

Thanks everyone for your useful comments 😉

[brettburwell]

Hi @xavierfoucrier.

That's great news! Thanks for taking a second look at this issue and reconsidering.