Consider adding an expandable "region"

[scottaohara]

From the ARIA WG call today, we talked about a clickable "region / card / section of content" that expanded/collapsed to reveal more or less content.

The context being that Aaron was discussing a use case where the parent element was a button that expanded and collapsed, and complex content was nested within this button, rather than as a sibling to it, and this being a use case as to why child presentation was removed from button roles in chrome/firefox.

Rather than repeat that discussion here - it was mentioned that we could come with a pattern to sort of replicate this use case, but without needing to nest the content within a button - but still making the card/content/region/whatever fully clickable to expand/collapse.

For instance, design an expanding/collapsing card component where there's an icon (plus / minus) in one of the corners to serve as the actual button - and use javascript to otherwise make the entire card clickable / change the state of the button.

[scottaohara]

a quick example of how i interpreted the component being discussed today - built in a way where the content does not need to be nested within a button - but the whole block/card is still clickable

https://codepen.io/scottohara/pen/ZYzRVmg

instance 1 has a visible button to show/hide the content that is hidden via inert in the default state.

instance 2 is the same markup structure, but with the button visually hidden.

both instances have a focus indicator around the entire card that appears when the button within each instance is focused - so even instance 2 not having a visible button, there is still a focus indicator that appears for the 'card'

[css-meeting-bot]

The ARIA Authoring Practices (APG) Task Force just discussed Issue 3215 - Expandable region example.

The full IRC log of that discussion

<jugglinmike> Topic: Issue 3215 - Expandable region example
<jugglinmike> github: https://github.com//issues/3215
<jugglinmike> Matt_King: This came up in the ARIA working group meeting
<jugglinmike> Matt_King: There is possibly the need for an example that is like a disclosure but which is distinct due to: a larger click target, a different example/collapse icon, and the mouse behavior.
<jugglinmike> Matt_King: I hope I'm representing this well. We might want to have Scott give more input
<jugglinmike> Matt_King: The description of this issue is, I believe, fairly complete
<jugglinmike> Matt_King: This originally came up because people are nesting content inside of a button. You click the button, and the content appears. That of course is a problem, and it was suggested that the APG give a better alternative
<jugglinmike> Matt_King: One of the requirements (which Scott does address) is that there is something visible which means "expand" and which would also be focusable
<jugglinmike> Jem: I like Scott's idea
<jugglinmike> Jem: Do you see any concerns about this proposal?
<jongund> https://codepen.io/scottohara/pen/ZYzRVmg
<jugglinmike> siri: My only concern is that the entire "card", if you made it focusable, wouldn't that be too much for the screen reader?
<jugglinmike> Matt_King: Scott said the "plus/minus" would be used by screen readers
<jugglinmike> Matt_King: I think they're talking about a larger chunk of content being clickable
<jugglinmike> jongund: In his example, he's showing partial text (the first paragraph of an article), and if you click, it expands to show all of the text
<jugglinmike> jongund: That's a pretty common patter that you see in a lot of websites
<jugglinmike> jongund: One of his examples has an "expand/collapse" button, and that's what becomes focusable
<jugglinmike> Matt_King: Is the actual focus only on the "plus/minus" but it's only drawn around the entire card?
<jugglinmike> Jem: It's on the entire card
<jugglinmike> Matt_King: The screen reader would describe the entire card, then, and that's a bad user experience
<jugglinmike> jongund: does the screen reader need to know anything? They have access to this regardless
<jugglinmike> Matt_King: We don't want screen reader users to think that something is visible when it isn't (or vice-versa)
<Jem> https://codepen.io/scottohara/pen/ZYzRVmg
<jugglinmike> jongund: Okay, well, what if when you have a little box that's scrollable--does the screen reader know that there is scrollable content on the page?
<jugglinmike> Matt_King: They don't have to know that, necessarily
<jugglinmike> Matt_King: I'm always hoping that the part that I'm reading is visible to other people
<jugglinmike> siri: I just ran NVDA on this example. It is not reading the text when it isn't visible. When I get to the card, it reads the title of the card. It tells me the content is collapsed.
<jugglinmike> Matt_King: Is the resolution as simple as turning Scott's example into an APG example?
<jugglinmike> jongund: I think it could be that straightforward
<jugglinmike> Matt_King: That's good, I think. I'll get this back on the agenda for next week so we can talk about next steps. It does seem like there's a practical path forward based on what's Scott's saying
<siri> also heading is narrated as clickable by NVDA
<jugglinmike> Matt_King: I hear what you're saying, though, siri. I don't like the fact that you have to go backward, either
<jugglinmike> Matt_King: Okay, we're at time. We'll get to the landmarks issue next week
<jugglinmike> Zakim, end the meeting

[scottaohara]

responding to some of the minutes:

siri: My only concern is that the entire "card", if you made it focusable, wouldn't that be too much for the screen reader?
...
Matt_King: The screen reader would describe the entire card, then, and that's a bad user experience

the entire card isn't focusable. only the button within is. A focus indicator is put around the entire card, but that is purely styling - and purposefully done since these are the types of designs people are making, and thinking they need to put all the content in the buttons. but using modern CSS, you don't need to make such mistakes AND you can still get the design one wants.

also heading is narrated as clickable by NVDA

I didn't add anything into this to try and override default behavior from screen readers. since the entire section is clickable due to the click event listener on the entire "card", NVDA will announce it as clickable, since it is. That could be mitigated by adding another wrapping element that had the click handler on that new element instead. Then, putting role=none on that element would negate the 'clikcable' announcement, while it still would be. but i've found there are mixed opinions on doing things like that, and i opted to not introduce "clever" code into the examples.

[daniel-montalvo]

also heading is narrated as clickable by NVDA

I didn't add anything into this to try and override default behavior from screen readers. since the entire section is clickable due to the click event listener on the entire "card", NVDA will announce it as clickable, since it is. That could be mitigated by adding another wrapping element that had the click handler on that new element instead. Then, putting role=none on that element would negate the 'clikcable' announcement, while it still would be. but i've found there are mixed opinions on doing things like that, and i opted to not introduce "clever" code into the examples.

And also there's an NVDA setting to mute "clickable". I don't think we need to hack around this, we may end up causing more problems.

I think there is value on the screen reader users knowing that it's not just the button what they can click/press, but also the part of the paragraph that is visible. There is a use case where you'd get to the button, you may or may not be interested in expanding it, you'd get past it, start reading the part of the text that is visible and change your mind. If we don't convey that "the whole visible area can be clicked to be expanded, most users will need to go back to the button (maybe a couple up arrow/left flicks) because they'd think that's the only way they can expand the region. Now with Scott's example you can press Enter key and expand it in any part of the visible area due to built-in screen reader functionality that emulates the left click when the user presses Enter. I wonder if the whole visible area should get the "collapsed" state for the screen reader users to make it easier for them to expand it wherever they are in the region.

[scottaohara]

I wonder if the whole visible area should get the "collapsed" state for the screen reader users to make it easier for them to expand it wherever they are in the region.

definitely a thought - though exposing the expanded state is not something that isn't consistently supported, if at all on container elements. Though, if an expanded state change of the button could be communicated, even if the button wasn't the element that was directly pressed, then that would potentially be a way to communicate that the clicking expanded something, without needing to get expanded state support on container elements.

[css-meeting-bot]

The ARIA Authoring Practices (APG) Task Force just discussed Consider adding an expandable "region".

The full IRC log of that discussion

<jugglinmike> Subtopic: Consider adding an expandable "region"
<jugglinmike> github: https://github.com//issues/3215
<jugglinmike> Adam_Page: I finished an initial prototype
<jugglinmike> Adam_Page: I used Scott O'Hara's prototype as a starting point
<jugglinmike> Adam_Page: I built on it, using hypothetical real-world content instead of lorem ipsum
<jugglinmike> Adam_Page: I reviewed the minutes of the ARIA Working Group and found an example from Aaron Leventhal (sp?)
<jugglinmike> Adam_Page: I built on that concept
<jugglinmike> Adam_Page: I wanted to cover nested focusables, as well
<jugglinmike> Adam_Page: In Scott's example, everything that is expanded is static content. I wanted to support if there was more content in there
<jugglinmike> Adam_Page: Also, when you click expand, I put programmatic focus on the "expand" button
<jugglinmike> Adam_Page: And I added cursor support for selecting text within the interactive area
<jugglinmike> Adam_Page: I haven't committed anything to the repository, yet, but I do have a CodePen link that I can share
<jugglinmike> Adam_Page: I wanted to check in with you folks about the timeline
<jugglinmike> Adam_Page: Like Matt_King, I am also headed overseas next week. I don't know if that factors into the timing, but at the very least, I can have this up for review before I go
<jugglinmike> Matt_King: Sure. If you want to make a "draft" pull request, that will give us something to look at
<jugglinmike> Matt_King: There's also the table for roles, states, and interactions. Could you add that?
<jugglinmike> Adam_Page: I can do a draft pull request for the pattern itself, but I've been intentionally holding off on pattern documentation because I expect there to be some churn while we play with the example and discuss how it ought to behave
<jugglinmike> Matt_King: Yeah, that makes sense. Maybe you can just include an empty table in your "draft" pull request
<jugglinmike> Adam_Page: Sure
<jugglinmike> Matt_King: As I think about how we test these things in the ARIA-AT project, sometimes it's a really good idea to have a super-basic example that has as few interactions as possible but still covers the most basic stuff required for interoperability. And then, separately, something fancier
<jugglinmike> Matt_King: Specifically, I'm thinking about the nested focusables. I'm wondering if we want one example with those and one without because they may have different levels of support...
<jugglinmike> Adam_Page: That seems plausible. The nested focusables certainly felt like the most complicated aspect, initially
<jugglinmike> Adam_Page: But where I landed, it doesn't seem like the removal of those nested focusables will lead to a change that needs to be documented
<jugglinmike> Matt_King: Well, lets start with what you have then, and we can have a discussion about simplification as part of our review
<jugglinmike> Adam_Page: It took a little extra finesse to ensure that when a user uses a keydown, it doesn't interfere with text selection
<jugglinmike> Adam_Page: That the user should be allowed to click and drag with a pointing device without triggering the "collapse" behavior
<jugglinmike> Adam_Page: If it's collapsed, they should be able to select text (and copy it to their clipboard), and the same goes for the "expanded" state
<jugglinmike> Matt_King: I don't know if that would show up in the accessibility features or not, but commenting about it in your code would be helpful
<jugglinmike> Matt_King: You might want to mention it in the accessibility features, though. I don't know
<jugglinmike> Adam_Page: Yeah, I don't know if that ties back to anything normative. It could just be a case where we took special care
<jugglinmike> Matt_King: Selection is important for things like "select to speak"
<jugglinmike> Adam_Page: You mean, like, voice control?
<jugglinmike> Matt_King: Mac and Windows both have a feature where you can select text to have it spoken
<jugglinmike> Matt_King: So if you can't select text, you can't have it spoken. That's one way selection ties directly to accessibility
<jugglinmike> Adam_Page: Got it
<Adam_Page> https://cdpn.io/pen/debug/PwYMopM
<jugglinmike> Matt_King: So let's create a "draft" pull request with a skeleton table. That will generate a preview, and we can play around with it
<jugglinmike> Matt_King: Then we can discuss timeline when you return
<jugglinmike> Adam_Page: I shared a link to the example as hosted by Codepen