Chapter  

https://github.com/w3c/aria-practices/issues/3215 https://github.com/w3c/aria-practices/pull/3251 https://deploy-preview-428--aria-practices.netlify.app/aria/apg/patterns/disclosure/examples/disclosure-card/

When the user’s keyboard focus moves to an interactive element, screen readers announce the type of the element (defined by its implicit or explicit ARIA role), the element’s accessible name (when it hopefully has one), the element’s state, if it has one, and finally any accessible descriptions associated with the element.

We will talk about accessible names and descriptions in far more detail in upcoming chapters. For this chapter, suffice it to say that when an interactive element can get its accessible name from its contents, and unless the name is explicitly specified using ARIA attributes, then the browser will announce the contents of the element as the accessible name.

All the contents of the button are announced as one long string of text, regardless of how long the contents are.

That said, buttons can only have specific types of content in them.

So, how do you implement patterns like expandable regions?

When you have a region that expands to reveal more content, this is technically a disclosure pattern. A disclosure pattern needs an interactive element: a button, to trigger the toggling of additional content.

So how do you implement this pattern? By design, this disclosure can be activated by clicking or tapping anywhere on the visible part of the region.

Knowing what we know about disclosure widgets, it might be tempting to think: we’ll just wrap the entire visible part in a <button>, and add the disclosure behavior like we discussed in the previous chapter.

Technically, wiring up the disclosure behavior is going to be as simple as what we learned in the previous chapter. The challenge—and the purpose of this chapter—is to understand what constitutes the interactive part of the disclosure in this pattern, and how to semantically define and mark up the region.