Disclosure pattern - Partially hidden content

[gaurav5430]

All the examples on https://www.w3.org/TR/wai-aria-practices-1.1/#disclosure talk about patterns which show/hide the complete dependent content.

Are the same practices also applicable for partially hidden content? Can a Read more / Read less button (and the content it controls) be considered a disclosure pattern example?

Something like this:

[carmacleod]

Yep, that's a disclosure. The main idea is to have aria-expanded="true"/"false" on the button.

I'm not quite sure how users will discover that the added content is before the button, though. Adding aria-controls="id-of-added-content" may help with that in some screen readers. I don't think you would want to go the route of putting the added content after the button in the DOM and then CSS'ing it into place... that seems like a bad hack.

Hopefully others will chime in here.

[scottaohara]

yes, still a type of disclosure widget, but changing the name of the control as well as the state would be a bit awkward though.

might this be more appropriately filed over in APG vs the ARIA spec?

[carmacleod]

changing the name of the control as well as the state would be a bit awkward though.

Good point: "Read more, collapsed" and "Read less, expanded" would be confusing.

might this be more appropriately filed over in APG vs the ARIA spec?

Also a good point. :)

[gaurav5430]

Based on the comments, these seem to be the problems to solve:

• changing state as well as name would be confusing.
• the content is before the button in the DOM which might require a different handling than the examples

I would like to add another point about the content already being partially visible, would that require a different handling as compared to the examples?

[mcking65]

Agree purely APG ... will take it up over there.

[carmacleod]

@mcking65 Actually, this is the APG repo... @jnurthen transferred the issue here yesterday. :) Hope it's ok if I reopen.

[mcking65]

Oops, when I saw the transfer comment, I thought it was still an ARIA issue and the APG issue was separate. I didn't realize I was in APG repo. That transfer feature is nice. Thanks for re-opening.

[mcking65]

In the button pattern we have the following in the description of a toggle:

Important: it is critical the label on a toggle does not change when its state changes. In this example, when the pressed state is true, the label remains "Mute" so a screen reader would say something like "Mute toggle button pressed". Alternatively, if the design were to call for the button label to change from "Mute" to "Unmute," the aria-pressed attribute would not be needed.

We should add similar text in the disclosure pattern. Also, with a disclosure it is certainly valid to change the button name instead of using aria-expanded.

I believe we address this in the pending work on a guidance section for widget states.

While I can't see the images, I am guessing this is a typical situation where you have truncated content and an button that exposes the remaining content, similar to the "see more" in a truncated Facebook post.

This particular use case doesn't quite fit the APG disclosure pattern. It is certainly similar, and if we were to modify the pattern to suggest the option of changing the button name instead of using aria-expanded, it would be even more similar.

The APG pattern is meant to be a typical toggle behavior. So, focus does not move. You can keep activating the button and showing/hiding. And, the new content immediately follows the control in the reading order.

In this case, you have the tricky situation that the "see less" button (if there is one) usually floats to the end of the text. But, you definitely do not want focus to go with it or screen reader users will chop your head off if your neck is within reach and they have the necessary weapons and personality. Like everyone else, screen reader users want to keep reading just where they left off. So, you need to be sure that it is placed on an element containing the most suitable place to keep reading. This should also not force the user back to the beginning and make them re-read what they just read.

I haven't seen many scenarios like this where there is a "see less" button. In the few that I have, I've wondered if anyone ever uses it. Regardless, I believe that activating "see less" should put focuss on the "see more".

If the group does want to cover this use case with the disclosure pattern, we could certainly do so. It would be a rather significant revision.

To address your questions though:

1. Recommend changing button name and not using expanded.
2. When activating "see more", place focus at the start of the newly rendered content.
3. When activating "See less", place focus on "See more"
4. As with current disclosure, aria-controls is certainly optionaal. In this case, putting it on "see less" might add some meaningful value for users of assistive technologies that have the ability to move to controlled element.