The best way to Accessibly Cut up Textual content

I not too long ago revealed an article on animating variable fonts with the assistance of the Javascript library Splitting.js. A couple of individuals requested concerning the accessibility implications of this, so on this article we’ll check out why splitting a string of textual content could be problematic from an accessibility perspective, and what we are able to do to ensure that cut up textual content is accessible to everybody.

Splitting.js recap

Let’s say you’ve a phrase, a heading, a paragraph or a sentence and also you need to change the fashion on a per-letter foundation. The best way that Splitting.js works is it wraps every character (together with whitespace characters) in a <span> tag and including numerous attributes that can help you extra simply goal and manipulate each. It additionally wraps every phrase in its personal span, so you may goal them individually too. There are lots of inventive prospects!

The next Codepen demo incorporates an instance of Splitting.js in motion, utilizing customized properties in CSS to calculate a color worth for every letter. On this article I’ll describe the methods I used to make it accessible.

See the Pen Splitting JS accessible textual content with ARIA attributes by Michelle Barker
(@michellebarker) on CodePen.

Why is splitting textual content an accessibility concern?

Some people who find themselves blind, partially-sighted, or discover studying on the net troublesome or problematic for various causes may use display screen reader software program to help them in navigating and exploring a web site. Display screen readers announce the content material of the webpage aurally to a consumer. To higher perceive the expertise of an individual utilizing a display screen reader, I like to recommend watching How A Display screen Reader Person Accesses The Net, an accessibility webinar from Smashing Journal.

That is one purpose why semantic HTML is particularly necessary: not everybody accesses our webpages visually, so utilizing the best HTML parts for the best function makes navigating the web page and discovering related content material a lot simpler.

We’d need to cut up a string of textual content for presentation functions, however altering the markup inside (for instance) a heading can have an effect on how screenreaders interpret the textual content and skim it again to the consumer. Contemplate the next markup – a easy <h1> heading tag:

<h1>Oh howdy there</h1>

Now let’s take a look at the identical heading cut up into spans:

<h1>
  <span>O</span>
  <span>h</span>
  <span> </span>
  <span>H</span>
  <span>e</span>
  <span>l</span>
  <span>l</span>
  <span>o</span>
  <span></span>
  <span>T</span>
  <span>h</span>
  <span>e</span>
  <span>r</span>
  <span>e</span>
</h1>

With every character wrapped in a person tag, some screenreaders is not going to interpret every phrase, however as an alternative announce every letter individually. This could not be a really useful expertise for somebody navigating the web page utilizing a screenreader!

This behaviour is just not constant between screenreaders. I initially examined this with VoiceOver on Safari, which has no issues studying the textual content as supposed. Others, nevertheless, omit the phrase breaks and skim the content material as a single lengthy phrase.

Making it accessible with WAI-ARIA

Fortunately, these accessibility considerations don’t imply that we are able to’t use cool libraries like Splitting.js. We simply must go to a tiny bit extra effort to make sure our textual content is accessible to everybody.

WAI-ARIA offers us with attributes for outlining how parts needs to be introduced to assistive applied sciences. Whereas it’s designed to assist make web sites extra accessible, it’s not an alternative choice to semantic HTML. It needs to be used when semantic HTML alone is just not sufficient.

aria-label

Within the case of our instance heading, we are able to present an accessible textual content label for display screen readers with the aria-label attribute:

<h1 aria-label="Oh howdy there">
  <span>O</span>
  <span>h</span>
  <span> </span>
  <span>H</span>
  <span>e</span>
  <span>l</span>
  <span>l</span>
  <span>o</span>
  <span></span>
  <span>T</span>
  <span>h</span>
  <span>e</span>
  <span>r</span>
  <span>e</span>
</h1>

Utilizing aria-label alone may cause some display screen readers to learn out the textual content to learn out each the textual content label and the content material. That is removed from best – we don’t need display screen reader customers to must take heed to the textual content being spelt out for them after listening to the label. so we have to cover the component’s inside content material from display screen readers, which we are able to do utilizing aria-hidden.

aria-hidden

aria-hidden hides the component from the accessibility tree, so a display screen reader will ignore it. We are able to’t cover the component itself, as then it gained’t be learn in any respect – however we are able to cover its youngsters. So we now have a alternative right here: we might add aria-hidden to every <span> in our heading:

<h1 aria-label="Oh howdy there">
  <span aria-hidden="true">O</span>
  <span aria-hidden="true">h</span>
  <span aria-hidden="true"> </span>
  <span aria-hidden="true">H</span>
  <span aria-hidden="true">e</span>
  <span aria-hidden="true">l</span>
  ...
</h1>

Or, if this feels slightly tedious, we’d select to group all the youngsters inside one other span, and add aria-hidden to that as an alternative:

<h1 aria-label="Oh howdy there">
  <span aria-hidden="true">
    <span>O</span>
    <span>h</span>
    <span> </span>
    <span>H</span>
    <span>e</span>
    <span>l</span>
    <span>l</span>
    <span>o</span>
    <span></span>
    <span>T</span>
    <span>h</span>
    <span>e</span>
    <span>r</span>
    <span>e</span>
  </span>
</h1>

Utilizing Javascript so as to add ARIA attributes

If we’re utilizing Spitting.js to create these baby parts, we are able to add aria-hidden="true" to every phrase through the use of a forEach loop. As I discussed earlier, Splitting splits a sentence into phrases and wraps each in a <span>, in addition to wrapping every character. Splitting() returns an array of goal parts, so we firstly must loop over each, then loop over every phrase inside the cut up component. Then we are able to verify if the component has an aria-label attribute, and if it does we add aria-hidden:

/* Loop by means of all cut up parts */
Splitting().forEach((s) => {
  /* Loop by means of phrases */
  s.phrases.forEach((phrase) => {
    /* If the mother or father component contains `aria-label`, set `aria-hidden="true"` */
    if (phrase.parentElement.getAttribute('aria-label')) {
      phrase.setAttribute('aria-hidden', true)
    }
  })
})

This can end in an HTML construction one thing like this:

<h1 aria-label="Oh howdy there">
  <span aria-hidden="true">
    <span>O</span>
    <span>h</span>
  </span>
  <span> </span>
  <span aria-hidden="true">
    <span>H</span>
    <span>e</span>
    <span>l</span>
    <span>l</span>
    <span>o</span>
  </span>
  <span></span>
  <span aria-hidden="true">
    <span>T</span>
    <span>h</span>
    <span>e</span>
    <span>r</span>
    <span>e</span>
  </span>
</h1>

The consumer solely hears the contents of the aria-label attribute, not the textual content contained in the component itself. That takes care of our accessibility considerations and means we are able to cut up the textual content content material of the component safely, figuring out that it will likely be accessible to all.

It will be nice if Splitting.js might do that by default, though there are a number of totally different issues to take into consideration for various kinds of textual content. There may be presently an open Github subject for including accessibility options.

Because of Andy Bell for signposting this accessibility resolution in my twitter feed after I revealed the unique put up!