Looks like we’re all the time speaking about clipping textual content round right here. All it takes is a bit searching to identify a bunch of issues we’ve already explored.
It’s more durable than it appears to be like! 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 complete textual content and publicizes it.
I began questioning: What if I or another person needed to learn the complete textual content however didn’t have the assistive tech for it? It’s virtually a selfish-sounding factor due to long-term muscle reminiscence telling me I’m not the person. However I feel that’s a legitimate request for a extra inclusive expertise. All people ought to be capable of get the complete content material, visually or introduced.
I didn’t need to make the identical demo, so I opted for one thing a bit totally different that poses comparable challenges, maybe much more so. That is it:
I do know, not the loveliest factor ever. But it surely’s an attention-grabbing case research as a result of:
This setup does what my MDN experiment doesn’t: give customers with out assistive tech a path to the complete content material. Proper on, ship it! However wait…
Now VoiceOver (I’m sorry that’s all I’ve examined in) publicizes the button. I don’t need that. I don’t even want that as a result of a display screen reader already publicizes the complete textual content. It’s not like somebody who hears the textual content must broaden the panel or something. They need to be capable of 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 must be current for listening to listeners as nicely.
If we had been to easily drop disabled="true" on the button, that stops the display screen 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 is likely to be lacking out on one thing even when I’m not. Plus, I don’t need to disable the button by default, particularly for many 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 offers 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 factor. Looks like the “proper” place to succeed in for ARIA.
We might “cover” the button this fashion:
<!-- NOPE! -->
<button aria-hidden="true">Present Full Textual content</button>Buuuut, slapping aria-hidden="true" on a focusable factor is not thought-about a finest apply. There’s an aria- strategy that’s equal to the disabled attribute, solely it doesn’t truly disable the button after we’re not utilizing a display screen 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 just 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 apply and noticed this demo as studying train. I discovered a pair other ways we will “describe” the button accessibly:
- Utilizing
aria-label: If our factor is interactive (which it’s), we will 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 likearia-labelhowever permits us to reference one other factor on the web page that’s used for the button’s description.
Let’s deal with that second one for a second. Which 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 publicizes the article content material.</span>The factor 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 certain that 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 folks. We will use some form of .visually-hidden utility class to cover the textual content inclusively in order that display screen readers nonetheless see and announce it:
.visually-hidden:not(:focus):not(:energetic) {
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 certain that 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 publicizes the article content material.</span>This actually does the trick! VoiceOver acknowledges the button, calls it out, and reads the .visually-hidden discover because the button’s description.
I’m fairly certain 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 factor was already on the web page and we determined to recycle it. We will get away with aria-label as a substitute 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 publicizes 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 instantly 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 to be like off to me. I do know that the button’s accessible title ought to come from the aria-label if one is offered, 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 factor.” 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 extensively 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 beneficial and can be hesitant to ship this. I’m certain an precise accessibility practitioner would have a extra knowledgeable opinion primarily based on testing.aria-describedby: We will leverage one other factor’s accessible description to explain the button identical to we did witharia-labelledby. Cool for certain, however not what we want proper right here since I wouldn’t need to introduce one other factor solely to cover it for its description.
However don’t simply take it from me! I’m feeling my approach by means of this — and solely partially so far as testing. This additionally is likely to be a totally dumb use case — hiding textual content is often 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 last demo as soon as once more. It’s editable, so be at liberty to poke round.
