Another Stab At Truncated Text

It seems like we’re always talking about cutting text here. You only have to browse a little to discover a lot of things we’ve already covered.

It is harder than it looks! And it requires a lot of thought! Last time I was here, I recreated a cool looking implementation on MDN.

There I noticed that VoiceOver takes the complete text into account and announces it.

I began to ask myself: What if I or someone else wants to read the full text but does not have the necessary assistive technology? It almost sounds selfish because my muscle memory tells me I am not the user. But I think that’s a legitimate demand for a more immersive experience. All people should be able to see all the content, visual or announced.

I didn’t want to do the same demo, so I decided to do something else that presented similar or maybe even greater challenges. That’s it:

I know it’s not the prettiest thing ever. But it’s an interesting case study because:

This setup does something my MDN experiment does not: it provides users without assistive technology a path to the full content. Exactly, send! But wait…

Now VoiceOver (unfortunately I only tested this) announces the button. I don’t want that. I don’t even want need that’s because a screen reader already announces all the text. It’s not like someone hearing the text needs to expand the panel or anything like that. They should be able to skip it!

But should we really “hide” the button? Many common opinions tell us that it terrible to hide and disable buttons. All controls available to sighted readers should also be available to hearing listeners.

If we just dropped disabled="true" on the button that prevents the screen reader from pressing the button to activate something unnecessarily. But now we have created a situation where we disabled something without even an explanation WhyWhen I hear that there is a button on the page and this disabled (or dimmed), I want to know why, because it sounds like I’m missing something, even if that’s not the case. Also, I don’t want to disable the button by default, especially for those who need it.

At this point, the “real” Geoff would probably pause and question the pattern altogether. When something gets this complicated, there’s probably a straighter path that I’m missing. But we’re all learners here, so I gave the other Geoff a shiny object and how he was distracted for hours.

Let’s say we really want to follow this pattern and make it so that the button stays in place but provides context to the help engineers. I know the first rule of ARIA is: “Don’t use ARIA” but we have crossed this metaphorical boundary by deciding . We don’t cram functionality into a

but they use a semantic element. Seems like the “right” place to reach for ARIA.

We could “hide” the button like this:

Show Full Text

But, slaps aria-hidden="true" on a focusable element is not considered a best practiceThere is a aria- Approach that corresponds to disabled Attribute, only it is not really disable the button if we are not using a screen reader.

Show Full Text

Cool, now it’s hidden! Send it. Oh, wait again. Yes, we have aria-disabled the button as far as assistive technology is concerned, but it still doesn’t say why.

There is still a lot to do. I recently learned a lot about ARIA after reading Sara Soueidan’s “The other C in CSS” presentation. I’m not saying I “got it” now, but I wanted to practice and saw this demo as a good learning exercise. I learned a few different ways we can “describe” the button in an accessible way:

• Using aria-label: If our element is interactive (which it is), we can use this to write a custom description for the button, assuming the accessible name of the button isn’t enough (which it isn’t).
• Using aria-labelledby: It is like aria-label but allows us to reference another element on the page that will be used to describe the button.

Let’s focus on the second point for a moment. It might look something like this:

Show Full Text
This button is disabled since assistive tech already announces the article content.

The element we refer to must have a id. And since an ID can only be used once per page, we need to make sure that this is the only instance of it, so it needs to be unique – more unique than my simple example. Once it’s there, though, we want to hide it because sighted people don’t need the extra context – it’s for specific people. We can do some kind of .visually-hidden Helper class to hide the text completely so that screen readers can still see and display it:

.visually-hidden:not(:focus):not(:active) {
  width: 1px;
  height: 1px;
  overflow: hidden;
  clip: rect(0 0 0 0); /* for IE only */
  clip-path: inset(50%);
  position: absolute;
  white-space: nowrap;
}

Let’s make sure we reference it in the CSS:

Show Full Text
This button is disabled since assistive tech already announces the article content.

It really works! VoiceOver recognizes the button, calls it and reads the .visually-hidden Note the description of the button.

I’m pretty sure I would send this. However, the markup feels heavy with hidden spanWe had to do this intentionally span just to describe the button. It’s not like this element was already on the page and we decided to recycle it. We can get away with it aria-label instead without the additional luggage:

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?
Read More

VoiceOver seemed to read things a little more smoothly this time. For example, it read the aria-label content immediately and announced the button and its state only once. If I left it to myself, I would call it “baked” and, yes, finally send.

But I’m not on my own, this probably isn’t enough. I double-checked the button in DevTools to see how the Accessibility API translates it.

This looks out of for me. I know that the accessible name of the button from the aria-label if one is available, but I also know that two other ARIA attributes are specifically designed for describing elements:

• aria-description: That’s probably what we want! MDN describes it as “a string value that describes or comments on the current element.” Perfect for our purposes. But! MDN Notes that this is still in the Editorial Draft of the ARIA 1.3 Specification. It shows broad support in Canius at the same time. It’s probably safe to use, but I’m oddly conservative about features that haven’t been officially recommended and would hesitate to ship this. I’m sure a real accessibility expert would have a more informed opinion based on testing.
• aria-describedby: We can use the accessible description of another element to describe the button, just like we do with aria-labelledby. Certainly cool, but not what we need here, as I don’t want to introduce another element just to hide it for its description.

But don’t just take my word for it! I’m feeling my way through this – and I’m only partially testing it so far. This could also be a completely stupid use case – hiding text is usually a bad thing, even small snippets like this. I expect we’ll get some tips from smarter people in the comments.

Here’s the final demo again. It’s editable, so feel free to browse around.