A disclosure widget can reveal – or disclose – hidden content under a heading. It saves screen space and provides a good overview of the page content.
Often, there is a symbol like a plus sign [+] or a downwards-pointing triangle ▼ next to the expandable heading to indicate that more content can be revealed. When the content has been revealed, this symbol typically changes to a minus sign or an upwards-pointing triangle ▲.
A disclosure widget in action
The website of the bank kfw.de uses disclosure widgets for text-heavy pages. Users can expand the headings and expand (disclose) content underneath.
A keyboard user focuses and activates headings of a disclosure widget.
- Reaching the heading, the color changes and the element is underlined. Its name, role and the state (collapsed) are announced by the screen reader.
- Activating the button discloses the text content underneath. The new state (expanded) is announced
- The user move on to other disclosure widgets and expands another one.
Typical usability problems with disclosure widgets
Often, disclosure widgets create problems for keyboard users and speech input users.
1 Keyboard use: Disclosure controls cannot be focused and activated
Often the elements that disclose content cannot be focused and activated with the keyboard. They carry a script that only responds to a pointer like a mouse cursor or touch. For keyboard users, they are completely inaccessible - even when the hidden sections contain focusable content like in this case.
Notice also the weak contrast of the disclosure controls (grey on white).
On the flybmi.com website, a keyboard user tries to reach the disclosure widgets on the page.
- He tabs through the navigation menu
- After the menu item "Ask", the focus jumps straight to the footer
- Tabbing through footer links and backwards, the focus jumps again over he content section
- Using the mouse, the disclosure widget can be opened
2 Speech input use: Disclosure controls cannot be activated by voice
When disclosure controls are not implemented using native links or buttons, they are inaccessible (or at least very hard to operate) for sprach inout users.
A speech input user tries to activate links on a web page.
- She can get the links to be numbered, but she cannot activate them by saying the number
- The disclosure widget controls "Bewilligungsstatistik" and "Verwendungsnachweisstatistik" cannot be activated - they are not implemented as proper controls using links or buttons (or by using ARIA roles)
- In contrast, the activation of the tabs in the tab panel below works, because the tabs have been implemented based on proper links.
Accessibility tips for discosure widgets
- Use heading markup for the elements that disclose content underneath. This way, screen reader users get an overview of content that they can navigate easily. An alternative can be definition list mark-up, for example, when you use disclosure widgets for a glossary or FAQ.
- Make sure the disclosed content comes right after the trigger that discoses it - not just visually, but also in the source code (DOM). Screen reader users can then simply arrow down to read the disclosed content.
- Use a button element as a trigger for disclosure. This way, the interactive heading will automatically receive keyboard focus. Do not make the trigger focusable by putting
- Leave the keyboard focus on the button when it is activated. Keyboard users can then easily toggle between expanded and collapsed state.
- Use the
aria-expandedattribute on the button. This value indicates whether the content is visible
- Keep the state up-to-date. Make sure the value of
aria-expandedchanges dynamically when a user interacts with the button.
- If you use a link as trigger, give it a
role=button. Activating the trigger will not go somewhere - it does something. That's why a link is not quite appropriate.
- Make sure the symbol has good contrast (3:1 or better).
- Include the symbol in the button so each disclosure trigger is just one tab stop. Use empty alternative text on the image; when you use font icons, hide the icon itself with
COMPARE cases with accessibility ratings
Resources for disclosure widgets
- WAI-ARIA Authoring Practices 1.1, 3.9 Disclosure (Show/Hide) (W3C Working Group Note, July 2018)
- Collapsible sections (Heydon Pickering, Inclusive Components, October 2017)
- Disclosure button design pattern:
buttonelement (Léonie Watson, Tink.uk, no date)