One other Stab At Truncated Textual content

Looks like we’re all the time speaking about clipping textual content round right here. All it takes is a bit shopping to identify a bunch of issues we’ve already explored.

It’s tougher than it appears! And there’s oodles of consideration that go into it! Final time I visited this, I recreated a cool-looking implementation on MDN.

In there, I famous that VoiceOver respects the total textual content and broadcasts it.

I began questioning: What if I or another person needed to learn the total textual content however didn’t have the assistive tech for it? It’s nearly a selfish-sounding factor due to long-term muscle reminiscence telling me I’m not the person. However I feel that’s a sound request for a extra inclusive expertise. All people ought to have the ability to get the total content material, visually or introduced.

I didn’t need to make the identical demo, so I opted for one thing a bit completely different that poses comparable challenges, maybe much more so. That is it:

I do know, not the loveliest factor ever. However it’s an attention-grabbing case examine as a result of:

This setup does what my MDN experiment doesn’t: give customers with out assistive tech a path to the total content material. Proper on, ship it! However wait…

Now VoiceOver (I’m sorry that’s all I’ve examined in) broadcasts the button. I don’t need that. I don’t even want that as a result of a display reader already broadcasts the total textual content. It’s not like somebody who hears the textual content must increase the panel or something. They need to have the ability to skip it!

However ought to we actually “cover” the button? A lot typical knowledge on the market tells us that it’s horrible to cover and disable buttons. Any management that’s there for sighted readers ought to be current for listening to listeners as effectively.

If we had been to easily drop disabled="true" on the button, that stops the display reader from urgent the button to activate one thing needlessly. However now we’ve created a scenario the place we’ve disabled one thing with out a lot as a proof why. If I’m listening to that there’s a button on the web page and it’s disabled (or dimmed), I need to know why as a result of it feels like I could be lacking out on one thing even when I’m not. Plus, I don’t need to disable the button by default, particularly for individuals who want it.

That is the place “actual world” Geoff would probably cease and query the sample altogether. If one thing is getting this difficult, then there’s in all probability a straighter path I’m lacking. However we’re all learners right here, so I gave that different Geoff a shiny object and the way he’s distracted for hours.

Let’s say we actually do need to pursue this sample and make it the place the button stays in place but additionally provides assistive tech-ers some context. I do know that the primary rule of ARIA is “don’t use ARIA” however we’ve crossed that metaphorical line by deciding to make use of a <button>. We’re not jamming performance right into a <div> however are utilizing a semantic component. Looks like the “proper” place to succeed in for ARIA.

We might “cover” the button this manner:

<!-- NOPE! -->
<button aria-hidden="true">Present Full Textual content</button>

Buuuut, slapping aria-hidden="true" on a focusable component is not thought-about a greatest follow. There’s an aria- method that’s equal to the disabled attribute, solely it doesn’t truly disable the button once we’re not utilizing a display reader.

<button aria-disabled="true">Present Full Textual content</button>

Cool, now it’s hidden! Ship it. Oh, wait once more. Sure, we’ve aria-disabled the button so far as assistive tech is worried, nevertheless it nonetheless doesn’t say why.

Nonetheless some work to do. I lately discovered a bunch about ARIA after watching Sara Soueidan’s “The Different C in CSS” presentation. I’m not saying I “get” all of it now, however I needed to follow and noticed this demo as an excellent studying train. I discovered a pair other ways we are able to “describe” the button accessibly:

• Utilizing aria-label: If our component is interactive (which it’s), we are able to use this to compose a customized description for the button, assuming the button’s accessible title isn’t sufficient (which it’s not).
• Utilizing aria-labelledby: It’s like aria-label however permits us to reference one other component on the web page that’s used for the button’s description.

Let’s deal with that second one for a second. That may look one thing like this:

<button aria-disabled="true" aria-labelledby="discover">Present Full Textual content</button>
<span id="discover">This button is disabled since assistive tech already broadcasts the article content material.</span>

The component we’re referencing has to have an id. And since an ID can solely be used as soon as a web page we’ve gotta be sure that is the one occasion of it, so make it distinctive — extra distinctive than my lazy instance. As soon as it’s there, although, we need to cover it as a result of sighted people don’t want the extra context — it’s for sure individuals. We are able to use some type of .visually-hidden utility class to cover the textual content inclusively in order that display readers nonetheless see and announce it:

.visually-hidden:not(:focus):not(:lively) {
  width: 1px;
  peak: 1px;
  overflow: hidden;
  clip: rect(0 0 0 0); /* for IE solely */
  clip-path: inset(50%);
  place: absolute;
  white-space: nowrap;
}

Let’s be sure we’re referencing that within the CSS:

<button aria-disabled="true" aria-labelledby="discover">Present Full Textual content</button>
<span id="discover" class="visually-hidden">This button is disabled since assistive tech already broadcasts the article content material.</span>

This definitely does the trick! VoiceOver acknowledges the button, calls it out, and reads the .visually-hidden discover because the button’s description.

I’m fairly positive I might ship this. That mentioned, the markup feels heavy with hidden span. We needed to deliberately create that span purely to explain the button. It’s not like that component was already on the web page and we determined to recycle it. We are able to get away with aria-label as an alternative with out the additional baggage:

<p>Lorem ipsum dolor sit amet consectetur adipisicing elit. Quidem asperiores reprehenderit, dicta illum culpa facere qui ab dolorem suscipit praesentium nostrum delectus repellendus quas unde error numquam maxime cupiditate quaerat?
<button aria-disabled="true" aria-label="This button is disabled since assistive tech already broadcasts the article content material.">Learn Extra</button>

VoiceOver appeared to learn issues a bit smoother this time round. For instance, it learn the aria-label content material immediately and introduced the button and its state solely as soon as. Left to my very own units, I’d name this “baked” and, sure, lastly ship it.

However not left to my very own units, this in all probability isn’t as much as snuff. I inspected the button once more in DevTools to see how the accessibility API interprets it.

This appears off to me. I do know that the button’s accessible title ought to come from the aria-label if one is out there, however I additionally know two different ARIA attributes are designed particularly for describing parts:

• aria-description: That is probably what we wish! MDN describes it as “a string worth that describes or annotates the present component.” Good for our functions. However! MDN notes that that is nonetheless within the Editor’s Draft of the ARIA 1.3 specification. It exhibits up broadly supported in Caniuse on the similar time. It’s in all probability protected to make use of however I’m unusually conservative with options that haven’t been formally advisable and can be hesitant to ship this. I’m positive an precise accessibility practitioner would have a extra knowledgeable opinion based mostly on testing.
• aria-describedby: We are able to leverage one other component’s accessible description to explain the button identical to we did with aria-labelledby. Cool for positive, however not what we’d like proper right here since I wouldn’t need to introduce one other component solely to cover it for its description.

However don’t simply take it from me! I’m feeling my method by this — and solely partially so far as testing. This additionally could be a very dumb use case — hiding textual content is normally a foul factor, together with little excerpts like this. I’m anticipating we’ll get some ideas from smarter people within the feedback.

Right here’s that ultimate demo as soon as once more. It’s editable, so be happy to poke round.